Testing in the Twenties - Tim Bray:
- Unit tests are an essential investment in your software’s future.
- Test coverage data is useful and you should keep an eye on it.
- Untested legacy code bases can and should be improved incrementally
- Unit tests need to run very quickly with a single IDE key-combo, and it’s perfectly OK to run them every few seconds like a nervous tic.
- There’s no room for testing religions; do what works.
- Unit tests empower code reviewers.
- Integration tests are super important and super hard, particularly in a microservices context.
- Integration tests need to pass 100%, it’s not OK for there to be failures that are ignored.
- Integration tests need to run “fast enough“.
- It’s good for tests to include benchmarks.
I think we’ve just had a new Testing manifesto. Agree with most of the explanations to those ten points too.
Update: There is a great comment from Jim:
Nice article. I’d say I have 2 peeves though.
One is your comments about TDD. No offence, but I’ve seen similar remarks a lot, and you’re a bit offbase there. The reason you don’t TDD early on is precisely the same reason I’m pretty strict about it. I’ve noticed that (the more reasonable of) those of us that are, treat TDD mostly as a design exercise, not a testing one. We just get tests as a bonus. And of course, sometimes the tests need to change, and some I throw away. Your perspective sounds like that of many other people I’ve worked with who are looking at it wrong. Something to consider, maybe.
I also do “exploratory testing” when trying out new libraries, techniques etc, especially in spikes. I find it helps to keep the crap tests then, as a warning for later :-)
Secondly, I think needing to make private methods public in order to test them is a code smell. Almost all the time, there is another class trying to get out. Somewhat more rarely, there is code in private methods that cannot be exercised by calling the public ones, which means there is unnecessary code in the private ones, and it can safely be removed. It’s not that I’ve never done this, but I can’t remember how long ago the last time was.
Everything else I think is very well expressed.
I have very similar thoughts to Jim’s while reading this article.
We should think of TDD as a helpful practice (for some people) to create well-designed, well-tested code instead of considering it “the best and only way to archive self-testing code.”
I do make private methods/properties internal to test their internal state sometimes because it’s easier that way. However, I have to think about those cases a lot and also consider them code smells.
Thanks a lot guys.
Another update: Very quickly, Mr. Fowler himself steps up and publish his take on the subject.
And as usual, he points out the exact problem - very clearly with pictures. Please go ahead and read the whole thing since quoting his entire post would be weird.
Thanks again, guys!