So for at least the last week I have been battling trying to tame the savage Integration tests that we inherited from forking the Android Development Tools. I’ve re-captured in the last couple of years my passion for Role Playing Games and Boardgames in general. Working on these tests and trying to get them to run outside of their original intended environement, has been like rolling a D20 die, and rolling a 1 when you really needed a critical hit 20. Time and Time again.
However, I finally, managed to roll that 20 last night, and the vast majority of the tests are now running. I’ve created a wiki page that documents most of the setup requirements in order for you to run the tests as part of your build locally. It was important to get these running, as during my investigation it didn’t appear that Google had any of these tests running together as part of their old basebuilder build. There were only the unit tests, and then an ApiDemo test that were set to run as part of the build.
The problems mainly came around the fact that you needed to have certain Android Platform APIs installed along with there sample applications. You also need to setup a special environment variable ADT_TEST_SDK_PATH that points to the location where you have your Android SDK installed. In addition for the CI server at Eclipse we needed to set the ADBHOST environment variable to point to the local machine so that DDMS that starts up as part of plugins during integration tests does not toss a dialog up on the screen.
I do want to point out a very handy set of classes that can be used along with the Integration Tests in case you get UI dialogs that pop up during your tests. DialogMonitor is a class from eBay’s Turmeric project. While that project is pretty much dead, grabbing the DialogMonitor and it’s supporting classes is worth while. It will basically monitor for any Dialog that pops up on the screen, and dismiss it to keep the UI thread available for your tests if they need it.
The other thing that was happening, none of the tests were isolated from each other. They were leaving dirty workspaces behind, and re-using the same project. So, now, all the tests create their projects, and then remove the projects and files. Also the tests have been converted to use JUnit 4, and if they needed temporary directories or files, the TemporaryFolder rule is being used to provide that. The boy scout motto applies when you are writing tests….leave your camp site in better shape than you found it. For tests, always clean up after yourself.
With the tests now running, we have a bit of a safety net going forward for any code change. Code coverage is still not good, but at least we have some sort of net even if it has holes to at least try and catch breaking changes in functionality. We will need more tests and more code coverage, but I’m more comfortable accepting contributions now that we have these tests running.
If you are looking for areas to contribute to the project, and want a good way to learn about the various plugins, we can use help getting the rest of the unit tests running, as well as getting tests in place for the existing code that is not being covered. Andmore will be at the Eclipse Hackathon, so these types of things are great opportunities for those wanting to contribute to the project but don’t want to start with a big feature. Also we have lots of FindBugs reports to address as well.
Andmore is really going to succeed or fail based on the user community it attracts. Our goal is to make it as open and easy as possible for people to contribute. Getting the tests running was one small step in that process.