Testing Basics

In this entry I just want to go through basic testing terms,  types and practices. 

First, we start with the vocabulary defined by Gerard Meszaros. He introduced the overall term Test Double for classes or technology that pretend to be some dependency needed by the class under test. A further destinction based on the completness of simulating the needed behavior can be established.

• Dummy - objects that are not really used, e.g. to fill the parameter list.
• Stub - objects that are partially implemented so testing with that dependency gets possible, e.g. base implementation of a needed interface, so no exception is thrown.
• Mock - objects created by mocking frameworks, Thereby it is possible to define the expected input  parameters and wanted return values.
• Fake - fully working implementations, but not directly suiteable for production e.g. in-memory database.

Secondly, I want to go through some testing types not so commonly known and often missunderstood.
Smoke Testing is a  small integration test used to find out if the system as a whole still works, e.g. "does the login work", "does that big very important button do something". This kind of testing tells us if we can go on with further tests. If something goes wrong (smokes) already, we know we broke impotant parts of the system. So it is not possible to proceed with other tests.
Furthermore, it can be used after a code review and before checking the code into the product source tree. Thereby, we can say the whole system still works as expected and the checked in code does not destabilize an entire build.
In contrary, Sanity Testing concentrates on a small subset of functionality, but is also used to determine if it works in general, e.g. some calculations within a financial application.
However, both approaches are used to save time and money, as both tell us if we can or should proceed with further testing.

The next part is about a practice I read in Dan North's article "Introducing BDD". In short, the name of your test methods should be real sentences to create a really readable low level documentation. Here you can find a tool, that stripps everything out and renders your class into a simple documentation text.
As an example:

public class FooTest extends TestCase {
    public void testIsASingleton() {}
    public void testAReallyLongNameIsAGoodThing() {}
}

would render to

Foo
- is a singleton
- a really long name is a good thing

Another interesting article I can recommend is from Gojko Adzic about Google trying to find testing metrics (determine if a test is good or bad). To find out if your unit test is of good quality, try to make some minor code changes and see if the test fails. Furthermore, consider you have a failing test:

"If the code was changed or added, the test was marked as good. If people changes the test code when it fails, it was marked as a bad test (especially if everyone is changing it)."

Mocks Aren't Stubs
Exploring The Continuum Of Test Doubles
Guidelines for Smoke Testing
Introducing BDD
Improving testing practices at Google