The Big TDD Misunderstanding

💡Originally the unit in “unit test” did not refer to the system under test but the test itself. Meaning the test can be executed as one unit and does not depend on other tests to run upfront (see here and here).

When people started to think of the unit as the system under test the quality of the tests suites went pretty bad. You change a little thing in your code and the only thing the tests suite tells you is that you will be busy the rest of the day fixing false positives.

There are two main styles when it comes to testing: mockist vs classicist. Here are my personal tips on how to write good tests mostly inspired by the classicist style.

Rule #1: Write the tests from outside in. Originally the test pyramid forbids a lot of end-to-end and integration tests. Instead the pyramid says we should write a lot of unit tests. This leads to an inside out approach testing the structure of the system rather its behaviour. I think this does not make much sense in a lot of projects. Challenge the traditional testing pyramid and think how much, end-to-end, integration and unit tests make sense in your context. Also consider more recent alternatives to the test pyramid: “Honeycomb” and “The Testing Trophy”.

Rule #2: Do not isolate code when you test it. If you do so, the tests become fragile and do not help you in case you refactor the software.

Rule #3: Only use mocks for truly external systems (e.g. mail service). The database should be part of the tests. Do not stub it.

Rule #4: Never change your code without having a red test. This is pretty common practice in TDD. This has two benefits: 1) it is the tests of the tests itself. When it is red, you know it works. 2) it makes sure you have a high test coverage.

from Hacker News https://ift.tt/tzTNrul