Google Testing Blog: August 2009

Update! Speakers & Talks for GTAC

Monday, August 17, 2009

4th Google Test Automation Conference (GTAC)

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)

http://www.gtac.biz

1 comment

Super Fast JS Testing

Wednesday, August 12, 2009

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:

http://js-test-driver.googlecode.com/svn/update/

For all you IntelliJ fanatics, there is something similar in the works.

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.

Javascript is a finicky language (Some people even hesitate to call it a language). And it can easily grow and become a horrible and complicated beast, incapable of being tamed once let loose. And testing it is a nightmare. Once you have decided on a framework (of which there are a dime a dozen), you then have to set it up to run just right. You need to set it up to actually run your tests. Then you have to figure out how to run it in a continuous integration environment. Maybe even run it in headless mode. And everyone solves it in their own ways.

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.

In java, all it takes is to click the run button in your IDE to run your tests. You get instant feedback, a green / red bar and details on which tests passed and failed and at what line. No context switch, you can get it to run at every save, and proceed on your merry way. Till now, this was not possible with Javascript.

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 in action

1 comment

The 7th Plague?

Monday, August 10, 2009

Yes, I only posted 6 plagues. Congratulations for catching this purposeful omission! You wouldn't trust a developer who argues "this doesn't need to be tested" or "that function works like so" and you shouldn't trust me when I say there are 7 plagues. In the world of testing all assumptions must be scrutinized and it doesn't work until someone, namely a tester, verifies that it does!

Clearly this is an alert and education readership. But why assume even this statement is true? How about another test? Anyone feel like contributing the 7th plague?

I've actually received a few via email already and I have an idea of my own 7th. So email them to me at [email protected] and I'll post a few of the best, with attribution, on this blog. Maybe I can even scare up some Google SWAG or a copy of my latest book to the best one.

First come, first published.

By James A. Whittaker
Yes, I only posted 6 plagues. Congratulations for catching this purposeful omission! You wouldn't trust a developer who argues "this doesn't need to be tested" or "that function works like so" and you shouldn't trust me when I say there are 7 plagues. In the world of testing all assumptions must be scrutinized and it doesn't work until someone, namely a tester, verifies that it does!
Clearly this is an alert and education readership. But why assume even this statement is true? How about another test? Anyone feel like contributing the 7th plague?
I've actually received a few via email already and I have an idea of my own 7th. So email them to me at docjamesw@gmail.com and I'll post a few of the best, with attribution, on this blog. Maybe I can even scare up some Google SWAG or a copy of my latest book to the best one.
First come, first published.

4 comments

TotT: Testing GWT without GwtTestCase

Saturday, August 08, 2009

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!

public void testRefreshPersonListButtonWasClicked() {
IMocksControl easyMockContext = EasyMock.createControl()
mockServer = easyMockContext.createMock(Server.class);
mockView = easyMockContext.createMock(View.class);
List franz = Lists.newArrayList(new Person("Franz", "Mayer"));
mockServer.getPersonList(AsyncCallbackSuccessMatcher<list<person>>reportSuccess(franz)));
mockView.clearPersonList());
mockView.addPerson(“Franz”, “Mayer”);
easyMockContext.replay();
presenter.refreshPersonListButtonClicked();
easyMockContext.verify();
}

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.

mockServer.getPersonList(AsyncCallbackFailureMatcher<list<person>>reportFailure(failedExpn))
expectLastCall().times(2); // Ensure the presenter tries twice

mockView.showErrorMessage(“Sorry, please try again later”));

You'll still need an end-to-end test. But all your logic can be tested in small and fast tests.

The Source Code for the Matchers is open-sourced and can be downloaded here: AsyncCallbackSuccessMatcher.java - AsyncCallbackFailureMatcher.java.

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.

This week's episode by David Morgan, Christopher Semturs and Nicolas Wettstein based in Zürich, Switzerland – having a real Mountain View

AsyncCallbackSuccessMatcher.java

AsyncCallbackFailureMatcher.java.

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.

GwtTestCase is good for testing UI-specific code in JavaScript. If you find yourself using GwtTestCase for testing non-ui client-side logic you may not have a clear View/Presenter separation. Separating the View and the Presenter allows for more modular, more easily tested code with shorter test times. Model View Presenter was introduced in another episode back in February. Here's how to apply it to a GWT app.

Defining terms:

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.