Unit tests are for developers. Integration tests are for users.

I was recently tasked with teaching a fellow developer about unit testing. Tim had no testing experience prior to joining the company. Tim had learned to write Webdriver tests over the past year, but now wanted to learn about unit testing.

The first point I covered is that unit testing is good for combinatorial tests. If you want to test a lot of different inputs, you’ll likely want to do it by writing unit tests because they are fast.

The second point I made is that the easiest methods to test are methods that map inputs directory to outputs. Sum(a, b) is a good example. The sum method’s return value is always dependent on its arguments, a and b.

Next I created an example where a module called out to another module in one of its methods. I showed how to mock the external module and proceeded to test that given an input the module under test called out to the mocked module.

Tim did not see any value to unit testing because it faked a lot of relevant code. Unlike integration tests, unit tests could not provide any guarantees that the users would be shipped a working product. He was right.

However, there are two types of tests required by developers. One type of test ensures that the users get a working product. These are integration tests and they can be quite slow and costly to run frequently. Usually, these tests should be run before a release to guarantee correctness and prevent regressions.

The second type of test ensures that developers are not breaking anything as they work. These tests need to run fast. They need to run every few lines of code we write. They need to run anytime someone else’s work is merged in. They need to pinpoint where in the code a mistake or unexpected behavior has occurred. These are the unit tests.