Set up test state using API when running tests via UI

When writing tests via UI it usually makes sense not to use UI for setting up application state. First, using UI for setup makes your UI tests even slower. Second, you may need to write some additional UI automation code simply for setup.

About dedicated QA

Do we need to have a dedicated QA in development team and what happens if we do not have dedicated QA?

Asynchronous assertions

In our current project we needed to test asynchronously executed logic. At the beginning we had only few of such tests so Thread.sleep was good enough for us. However, when the number of such tests started to grow we decided to implement better solution which is partly based on the idea described by Martin Fowler in his post.

Tips for writing readable tests

Following is list of best practices I try to follow when writing tests.

Using acceptance tests to drive development

I have seen experiments with acceptance test driven development in many teams over the years but it has never quite worked out. The tests have never become the main guiding lights for development. Sooner or later they have become simply the tools for tester while developers pay little or no attention to them. In recent project we tried it a bit differently. Instead of use cases or user stories/tasks we use acceptance tests as our main backlog items.

Power of EasyMock 2 with Java 1.4

I have been long time wondering if it is possible to improve API of EasyMock Java 1.3 version so that you get rid of MockControls in your test code. So as an experiment I wrote following classes to check how much work does this require. I wanted to achieve same simple API as in EasyMock 2.x but still be Java 1.4 compatible. Also I didn’t want to rewrite EasyMock or extend it in any fragile way.

Extending JUnit

I found that there is nice extension to JUnit called Unitils (http://www.unitils.org). It offers some generic utilities for unit testing, EasyMock mock object management, database testing (either plain JDBC or Hibernate). Also it’s integrated with DBUnit and Spring.

Functional testing in developer’s toolbox

Everybody knows that one should write tests in order to guarantee good internal and external software quality. In most cases developers focus on structural tests leaving high level functional testing to separate testing expert. However I believe that in many cases it can be useful to include functional tests in the process of writing production code same way as structural tests.

Lazy man’s mock pattern

Sometimes you want to test not only each class in isolation but subset of one class in isolation. I suppose that in many cases this means that you actually have something wrong in your design and you should consider splitting responsibilities of given class or make the API more fine grained. However sometimes above options are not that good – for example in case of legacy code. We don’t have time to refactor some old class but we still need to test if the code that we have added to it works correctly. In such situation I have started to use kind of a variation of self-shunt pattern.