- Testing Applications on Mobile Devices (Doron Reuveni, uTest)
- JsTestDriver (Jeremie Lenfang-Engelmann, Misko Hevery, Google)
- Fighting Layout Bugs (Michael Tamm, optivo GmbH)
- Even better than the real thing - Lessons learned from testing GWT applications (Nicolas Wettstein, Google)
- Selenium: to 2.0 and Beyond! (Simon Stewart, Google)
- Automating Performance Test Data Collection and Reporting (David Burns, David Henderson, smartFOCUS DIGITAL)
- Achieving Web Test Automation with a Mixed-Skills Team (Mark Micallef, BBC Future Media and Technology)
- Score One for Quality! (Joshua Williams and Ross Smith, Microsoft)
- Automatic workarounds for web applications (Antonio Carzaniga, Alessandra Gorla, Nicolò Perino, Mauro Pezzè, University of Lugano )
- Precondition Satisfaction by Smart Object Selection in Random Testing (Yi Wei, Serge Gebhardt, ETH Zurich)
Monday, August 17, 2009
Wednesday, August 12, 2009
by Shyam Seshadri
Before I jump into how exactly you can perform super fast and easy JS testing, let me give you some background on the problem.
But the biggest problem I have with most of these frameworks is that executing the tests usually requires a context switch. By that, I mean to run a JSUnit test, you end up usually having to open the browser, browse to a particular url or html page which then runs the test. Then you have to look at the results there, and then come back to your editor to either proceed further or fix your tests. Works, but really slows down development.
But now, we have JS Test Driver. My colleagues Jeremie and Misko ended up running into some of the issues I outlined above, and decided that going along with the flow was simply unacceptable. So they created a JS Testing framework which solves these very things. You can capture any browser on any machine, and when you tell it to run tests, it will go ahead and execute them on all these browsers and return you the results in your client. And its blazing fast. I am talking milliseconds to run 100 odd tests. And you can tell it to rerun your tests at each save. All within the comforts of your IDE. And over the last three weeks, I have been working on the eclipse plugin for JS Test Driver, and its now at the point where its in a decent working condition.
The plugin allows you to, from within Eclipse, start the JS Test Driver server, capture some browsers, and then run your tests. You get pretty icons telling you what browsers were captured, the state of the server, the state of the tests. It allows you to filter and show only failures, rerun your last launch configuration, even setup the paths to your browsers so you can launch it all from the safety of eclipse. And as you can see, its super fast. Some 100 odd tests in less than 10 ms. If thats not fast, I don’t know what is.
For more details on JS Test Driver, visit its Google Code website and see how you can use it in your next project and even integrate it into a continuous integration. Misko talks a little bit more about the motivations behind writing it on his Yet Another JS Testing Framework post. To try out the plugin for yourselves, go add the following update site to eclipse:
For all you IntelliJ fanatics, there is something similar in the works.
Monday, August 10, 2009
Saturday, August 08, 2009
Because GWT (Google Web Toolkit) is new and exciting it's easy to forget the lessons on clean GUI code structure that have been accumulated over nearly thirty years.
- Server – a completely standard backend with no dependency on GWT.
- Model – the data model. May be shared between the client and server side, or if appropriate you might have a different model for the client side. It has no dependency on GWT.
- View – the display. Classes in the view wrap GWT widgets, hiding them from the rest of your code. They contain no logic, no state, and are easy to mock.
- Presenter – all the client side logic and state; it talks to the server and tells the view what to do. It uses RPC mechanisms from GWT but no widgets.
The Presenter, which contains all the interesting client-side code is fully testable in Java!
Testing failure cases is now as easy as changing expectations. By swapping in the following expectations, the above test goes from testing success to testing that after two server failures, we show an error message.
You'll still need an end-to-end test. But all your logic can be tested in small and fast tests.
Consider using Test Driven Development (TDD) to develop the presenter. It tends to result in higher test coverage, faster and more relevant tests, as well as a better code structure.