Question

I’ve always worked alone and my method of testing is usually compiling very often and making sure the changes I made work well and fix them if they don’t. However, I’m starting to feel that that is not enough and I’m curious about the standard kinds of tests there are.

Can someone please tell me about the basic tests, a simple example of each, and why it is used/what it tests?

Thanks.

Answer 1

Different people have slightly different ideas about what constitutes what kind of test, but here are a few ideas of what I happen to think each term means. Note that this is heavily biased towards server-side coding, as that’s what I tend to do 🙂

Unit test

A unit test should only test one logical unit of code – typically one class for the whole test case, and a small number of methods within each test. Unit tests are (ideally) small and cheap to run. Interactions with dependencies are usually isolated with a test double such as a mock, fake or stub.

Integration test

An integration test will test how different components work together. External services (ones not part of the project scope) may still be faked out to give more control, but all the components within the project itself should be the real thing. An integration test may test the whole system or some subset.

System test

A system test is like an integration test but with real external services as well. If this is automated, typically the system is set up into a known state, and then the test client runs independently, making requests (or whatever) like a real client would, and observing the effects. The external services may be production ones, or ones set up in just a test environment.

Probing test

This is like a system test, but using the production services for everything. These run periodically to keep track of the health of your system.

Acceptance test

This is probably the least well-defined term – at least in my mind; it can vary significantly. It will typically be fairly high level, like a system test or an integration test. Acceptance tests may be specified by an external entity (a standard specification or a customer).

---

Black box or white box?

Tests can also be “black box” tests, which only ever touch the public API, or “white box” tests which take advantage of some extra knowledge to make testing easier. For example, in a white box test you may know that a particular internal method is used by all the public API methods, but is easier to test. You can test lots of corner cases by calling that method directly, and then do fewer tests with the public API. Of course, if you’re designing the public API you should probably design it to be easily testable to start with – but it doesn’t always work out that way. Often it’s nice to be able to test one small aspect in isolation of the rest of the class.

On the other hand, black box testing is generally less brittle than white box testing: by definition, if you’re only testing what the API guarantees in its contracts, then the implementation can change as much as it wants without the tests changing. White box tests, on the other hand, are sensitive to implementation changes: if the internal method changes subtly – or gains an extra parameter, for example – then you’ll need to change the tests to reflect that.

It all boils down to balance, in the end – the higher the level of the test, the more likely it is to be black box. Unit tests, on the other hand, may well include an element of white box testing… at least in my experience. There are plenty of people who would refuse to use white box testing at all, only ever testing the public API. That feels more dogmatic than pragmatic to me, but I can see the benefits too.

---

Starting out

Now, as for where you should go next – unit testing is probably the best thing to start with. You may choose to write the tests before you’ve designed your class (test-driven development) or at roughly the same time, or even months afterwards (not ideal, but there’s a lot of code which doesn’t have tests but should). You’ll find that some of your code is more amenable to testing than others… the two crucial concepts which make testing feasible (IMO) are dependency injection (coding to interfaces and providing dependencies to your class rather than letting them instantiate those dependencies themselves) and test doubles (e.g. mocking frameworks which let you test interaction, or fake implementations which do everything a simple way in memory).