Chapter 6 was about test hierarchies and Organization. It goes through several practical tips.
It starts off by telling us about the importance of automating the running of tests, and we agree there.
It also recommends separating between slow and fast tests (this pretty much should be read as unit tests and integration test) so that when you are coding you are more likely to run the tests at all times. Lukewarm on this idea, in some projects might make sense, however you could run into the trap of most tests are integration tests => tests are not run often enough => system brakes even thou you have unit tests => trust in the unit test is broken. But I think we can all see the point of this.
I don’t understand why there is a (small) section about ensuring tests are part of source control , why wouldn’t you put that there?
Then there is some advice about the code organization and naming conventions around it. Including the case where you need to create a unit separately just for a particular area of the unit because you need to write many tests for it, in this case the unit test class is called for example LoginManagerTestsChangePassword as a complimentary set of LoginManagerTests.
Then we hit possibly the most important part of this chapter: Building the test API for your application, this section recommends the use of inheritance creating new utility classes and methods and making your API known to the developers you work with. This is probably the best part of this chapter. The three methods discussed are described in an ok manner, perhaps the examples (particularly the one for abstract test infraestructure test pattern) are not incredibly descriptive, however they do describe the ways to build your API and the reasons behind why you would
do and use the methods.
Summing up
Good things about this chapter
- Unit tests should be part of your build cycle
- Spelling out the fact you need t build and maintain you tests API
Bad:
- a bit verbose
- examples not great
- Style not consistent ( ie there is no pattern on explaining why something is good bad, so you cant compare like with like)
One Comment
We put the following tests into slow test category:
Database tests (which are integration tests)
Temporal tests (i.e. tests where thread timing/synchronisation etc is involved – these usually are not integration tests.
When you have a codebase with a couple of thousand tests, where a few hundred tests take quite a bit of time, these tests must be separated into a slow test category.
All non-slow tests are executed by developers and all non-slow tests + slow tests are executed in our automated build process with cruise control