I'm making an essay about AngularJS vs EmberJS. In here I compare these two with different questions and at the end a decision is made for which one is better for developing web applications based on the answers of these questions.
One question that I have struggled with for EmberJS is about maintainability. I haven't been able to find one article that gives information about this, unlike AngularJS.
I would like to know how does EmberJS helps you maintain your EmberJS web application. What concepts or whatever, does it provide to help you achieve a high level of maintainability for your web applications build with EmberJS.
Thank you for any help regarding answering this question.
How does Ember help you maintain your application?
Some of this is subjective/debatable, but in the spirit of essays, here are some points for Ember in terms of maintainability:
Because Ember is so highly opinionated, it makes it really easy for other Ember developers to understand your project quickly and pick up where you left off. While the framework has a pretty infamous learning curve, once you're comfortable with Ember, most applications share a lot of similarities. Ember has a prescribed 'way' for doing most things -- from file structure to REST api interaction. If you've worked on one Ember project, moving in to do maintenance on another should feel very familiar. It's a big, standardized toolbox.
The Ember Inspector browser plugin gives you a lot of transparency into what's going on beneath the hood of your application. It's very helpful to debug and maintain Ember apps. I haven't really seen anything yet that's quite the same for other frameworks. (https://chrome.google.com/webstore/detail/ember-inspector/bmdblncegkenkacieihfhpjfppoconhi?hl=en)
Ember's handlebars templates don't allow you to put complex logic in your template. Any "if" check in a template must refer to a boolean value. This means less places to look to track down what you need to work on, and more testing of raw functions because your view isn't handling more than basic logic. It also encourages more readable templates.
Ember comes with built-in tooling for unit tests, integration tests, and end-to-end tests. This encourages devs to build tests for their applications or contribute to the existing tests of a project. Tests are good for maintainability.
Good luck!
Related
This question is subjective by nature, but I am curious about a specific thing, so hopefully there is a decent answer.
I tend to be a little old fashioned and like to create all my pages static and get the design just the way I like it (or at least very close) before I start breaking it down into handlebars and components and templates. This is mostly because the Ember "Getting Started" Guide taught me that process.
Is this the common practice, generally?
I am the front-end Designer and Developer for my company, and basically I have two separate workflows, one for Design, and one for Development/Testing.
Is there a way to merge the two and get a single streamlined workflow (perhaps a JS task that can split up static pages into templates by using some special markup??)
Design tends to be a little easier when you are working with static pages.
Development (especially when using EAK or Ember-CLI) expects everything to be modular and dynamic.
Is there any clear answer to this question?
I posted a similar question on Ember Forums, but have not gotten many view, so I figured I would try here.
Short answer when you're building an app with Ember you want to build around the URL structure, due to the way the URL and Router interact. Here's an awesome talk by Tom Dale about the URL. This makes it a very outside in approach, since each layer deeper in the url is content that's generally embedded 1 level deeper in the page.
http://vimeo.com/68390483
I'm a testing noob and I need to test a JSF application. So I only just started exploring JSFUnit (read: I've googled it and StackOverflow-ed it), which as I understand uses/extends JUnit, HTMLUnit, HTTPUnit and other units that I have no idea about.
The thing is, the app uses Hibernate and what I want to know is whether or not I can use JSFUnit to create comprehensive tests that encompass model, view and controller, not to mention all that the HTTPUnit supposedly does?
Also, if I'm using Primefaces Dialog Framework so that my dialogs are not in the same page that opens said dialog, would I be able to test this approach? Or would it be better, in terms of testing, if my dialog was on the same page?
I hope my questions make sense. I promise they made sense in my head. Any help in this regard would be highly appreciated.
It seems that you require something more complex than pure unit tests.
Take a look at Selenium framework, as it simulates user interaction through a real recorded use case, and is easy to work with.
I recently came across this nice article from David Ebbo about Unit Testing ASP.NET MVC razor views with the help of new Razor Generator tool. But I've been asking myself the question, what this can be best utilized for. Of course we can pass in a model and check if all the properties have been populated in to proper html as planned.
I'm new to this unit testing view business so need to get my head around what things to be Unit tested in razor views. Suggestions??
I've been wondering the same thing. I can think of a few basic things to check, such as:
HTML is valid/well-formed
Page title (<title>/<h1>) matches the title from the model
Model body appears in the page
Correct CSS/Javascript is included
Important links appear correctly (paging/purchase/more info)
Performance (If you have lazy-loaded models, there could be performance issues you could only spot as the code in the views enumerate/access data)
In a small app, this probably doesn't add a lot of value. However in a big app, testing the views could come in handy to ensure changes things aren't becoming broken as other changes are made (despite best efforts to keep things isolated, it's not entirely unusual to break something that you believe you never made changes to!).
I think you could come up with a few important tests to ensure major things in your app work, but you could only really catch things that would be really obvious with a very quick manual test (or even caught during dev). Some may consider this worthwhile, I guess it depends on the app/team.
Previous experience has taught me that maintaining tests against an ever-changing UI sucks (and if it's not often changing, the tests won't add much value). At my last company we spent so much time trying to fix up tests that became broken with updates to the app, we couldn't add new tests (though this was in part, due to the (crap, but expensive) software we used - Mercury QuickTest). Tests written in C# would probably be more maintainable, but you still need to really weigh up the maintaince work vs the benefit you'll get from the tests.
I m just starting using gwt and so far so good, however after reading some sample code I wonder is it necesary to have a high level of test coverage? (I can see that most code is declarative and then add some attributes I can see the sense in checking so me particular attributes are there but not all)
Also i would be interested to know anything about what are the gotchas in TDDing with GWT
I m using eclipse so also if you are really happy with some particualrs add ins for GWT I would be happy to hear about that
Thanks for the input
edit: maybe I m asking a very wide question, but even little pieces of information will help
I come from having nvelocity views with jquery/extJs/prototype/scriptaculous and this is a bit different
When designing GWT applications to be easily testable, it's best to move as much logic out of the view as possible. Use a design pattern which makes GUI testing easier such as Model-View-Presenter (MVP), which is used widely in building desktop applications (The C#/.NET folks have written a lot about this pattern.)
You can use GWTTestCases to test remote communication and code that ultimately executes raw JavaScript (most of the GWT core classes require this, especially widgets). However, these tests are slow to execute, so you should prefer designs which put all that logic in objects that can be tested in plain ol' JUnit TestCases.
For more information about writing GWT applications test-first, I've written an article for Better Software magazine, which is available as a PDF online at my blog.
I think the best reference at the moment would be this Testing Methodologies Using Google Web Toolkit
I think you asked a pretty broad question, which is part of the reason why you didn't get a reply for a while.
Compared to traditional AJAX web development, one could argue a GWT application requires less testing. Because the GWT team has worked so hard to make sure that its widgets work consistently across all web browsers, you don't have to worry about cross-browser compatibility nearly as much for your own application.
That frees you up to focus on your own application. Create a separate test case for each of your own custom widgets and test that they behave as you expect, and then write higher-level tests for each module. Take the extra step to make your tests fully automatable - that way every time you make a change or are about to release, it's easy to run all of your tests.
http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=google-web-toolkit-doc-1-5&t=DevGuideJUnitIntegration
Unit testing and ASP.NET web applications are an ambiguous point in my group. More often than not, good testing practices fall through the cracks and web applications end up going live for several years with no tests.
The cause of this pain point generally revolves around the hassle of writing UI automation mid-development.
How do you or your organization integrate best TDD practices with web application development?
Unit testing will be achievable if you separate your layers appropriately. As Rob Cooper implied, don't put any logic in your WebForm other than logic to manage your presentation. All other stuff logic and persistence layers should be kept in separate classes and then you can test those individually.
To test the GUI some people like selenium. Others complain that is a pain to set up.
I layer out the application and at least unit test from the presenter/controller (whichever is your preference, mvc/mvp) to the data layer. That way I have good test coverage over most of the code that is written.
I have looked at FitNesse, Watin and Selenium as options to automate the UI testing but I haven't got around to using these on any projects yet, so we stick with human testing. FitNesse was the one I was leaning toward but I couldn't introduce this as well as introducing TDD (does that make me bad? I hope not!).
This is a good question, one that I will be subscribing too :)
I am still relatively new to web dev, and I too am looking at a lot of code that is largely untested.
For me, I keep the UI as light as possible (normally only a few lines of code) and test the crap out of everything else. At least I can then have some confidence that everything that makes it to the UI is as correct as it can be.
Is it perfect? Perhaps not, but at least it as still quite highly automated and the core code (where most of the "magic" happens) still has pretty good coverage..
I would generally avoid testing that involves relying on UI elements. I favor integration testing, which tests everything from your database layer up to the view layer (but not the actual layout).
Try to start a test suite before writing a line of actual code in a new project, since it's harder to write tests later.
Choose carefully what you test - don't mindlessly write tests for everything. Sometimes it's a boring task, so don't make it harder. If you write too many tests, you risk abandoning that task under the weight of time-consuming maintenance.
Try to bundle as much functionality as possible into a single test. That way, if something goes wrong, the errors will propagate anyway. For example, if you have a digest-generating class - test the actual output, not every single helper function.
Don't trust yourself. Assume that you will always make mistakes, and so you write tests to make your life easier, not harder.
If you are not feeling good about writing tests, you are probably doing it wrong ;)
A common practice is to move all the code you can out of the codebehind and into an object you can test in isolation. Such code will usually follow the MVP or MVC design patterns. If you search on "Rhino Igloo" you will probably find the link to its Subversion repository. That code is worth a study, as it demonstrate one of the best MVP implementations on Web Forms that I have seen.
Your codebehind will, when following this pattern, do two things:
Transit all user actions to the presenter.
Render data provided by the presenter.
Unit testing the presenter should be trivial.
Update: Rhino Igloo can be found here: https://svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-igloo/
There have been tries on getting Microsoft's free UI Automation (included in .NET Framework 3.0) to work with web applications (ASP.NET). A german company called Artiso happens to have written a blog entry that explains how to achieve that (link).
However, their blogpost also links an MSDN Webcasts that explains the UI Automation Framework with winforms and after I had a look at this, I noticed you need the AutomationId to get a reference to the respecting controls. However, in web applications, the controls do not have an AutomationId.
I asked Thomas Schissler (Artiso) about this and he explained that this was a major drawback on InternetExplorer. He referenced an older technology of Microsoft (MSAA) and was hoping himself that IE8 will do this better.
However, I was also giving Watin a try and it seems to work pretty well. I even liked Wax, which allows to implement simple testcases via Microsoft Excel worksheets.
Ivonna can unit test your views. I'd still recommend moving most of the code to other parts. However, some code just belongs there, like references to controls or control event handlers.