In an interview of José by Theo Browne, they mention the importance of “good” tests, in contrast to “bad” ones.
Specifically, they started talking about this from this timestamp on.
It’s not the focus of the interview, however, and it’s more of a short tangent. They don’t go into detail about what makes a test good or bad.
But now I am actually curious about the answer.
What are your ideas about this topic? And are there any learning resources you can recommend that cover this topic?
What I try to make sure when writing tests is that I am testing behaviour, rather than implementation details. But maybe there are still a ton of ways to mess the tests up, besides that?
Some behaviours I’m coding seem to really call for tests. I might even feel lost without them. They help me write the function(s) with smaller cognitive load.
But sometimes I am writing tests for functions… And I don’t really see the benefit. Maybe the benefit is there, and I just don’t see it yet.
But it begs the question. When do you write tests? And when do you not?
An unnecessary test might also be considered “bad”, in some sense.
I’m not a big guru on writing good tests yet, however testing goes hand in hand with design, bad unit tests point to bad design. This is one of the reasons why TDD or BDD are such a great thing, you design the system from the start with testability in mind, and you will also get benefits like isolation and separation of concerns out of the box for free (if you write unit tests correctly ofc).
One of the lessons I learned the hard way is to always keep unit tests isolated, if you start to couple them you will have brittle tests that will start to collapse once you make some small changes, same goes for the detail implementations.
I didn’t watch the video, however this discussion popped a lot of times on this forum. Writing tests to check the types is in my opinion in category of those bad unit tests that check implementation details, however I have never seen those kind of tests in my career so maybe the wording is misleading.
I have a few rules of thumb when it regards tests:
test should stress edge cases, i’ll never know all edge cases at a glance, but everytime you find one, you should add a new test or at least change an existing test to cover that.
test shouldn’t have only the happy path.
test shoudn’t check library behaviour. libraries are not always 100% safe but if you don’t trust it to do what it says it does, you’d be better not using the library.
I think other stuffs apply, but they’re usually related with context of your codebase, what is more important and what is crucial for your application.
This is a can-of-worms topic I love talking about this stuff and could talk about it for hours (and I have!) even though I would still not call myself anything close to an expert.
I always had difficulties putting the “bad” label on tests. The only truly bad tests I can think of is checking if your libraries are working at all, and even that is not 100% because at one point you want any guarantee you can get so it does make sense to have integration-like tests that also check if your 3rd party dependencies do what you want them to do.
The objectively good tests to me are property tests. As @cevado said above, your tests should check the edge cases and property tests are really good at that (though within limits; it depends how well you have modeled your property test generators).
I’d say the best tests you can get are those that you feel are validating your app’s / library’s functionality about which you care the most. Don’t let others tell you what’s good or bad.
I love talking about this stuff and could talk about it for hours (and I have!) even though I would still not call myself anything close to an expert.
