DEV Community

Discussion on: How to write unit tests

Collapse
 
jonrandy profile image
Jon Randy 🎖️ • Edited

I've used automated testing extremely rarely over 26 years being a professional developer. It's possible to get on just fine with manual testing

Collapse
 
marcinwosinek profile image
Marcin Wosinek

I like a lot the reassurance that an extensive test suite gives me. In my main project, we have more than 3000 unit tests and about 400 E2E. I never worry about doing refactoring, library updates, weird coupling between code - if all automated tests passes, it's very improbably that anything is seriously broken.

Definitively you have a compound effect here - the longer your project lives, the longer you are getting benefits out of investment into writing tests. In my project, I wrote some E2E 6 years ago, and since then run them in the order of few tousands times.

Besides, writing or not writing tests is a decision on the project or team level. It would be frustraing and not productive to be the only developer caring about tests. In the oposit case, changes without tests simply wouldn't be aproved.

Collapse
 
jeremyf profile image
Jeremy Friesen

I like the language of "improbable that anything is seriously broken." It highlights the fact that our tests are useful in providing some degree of comfort but also that we shouldn't solely rely on them and assume they catch everything.

Automated tests are a long running conversation we have with our system, and as both change, drift inevitably occurs.

Collapse
 
peerreynders profile image
peerreynders

Testing is also about improving design.

The Flawed Theory Behind Unit Testing:

  • "One very common theory about unit testing is that quality comes from removing the errors that your tests catch. … It’s a nice theory, but it’s wrong."

  • "All of these techniques have been shown to increase quality. And, if we look closely we can see why: all of them force us to reflect on our code. When you write unit tests, … you scrutinize, you think, and often you prevent problems without even encountering a test failure."

  • "I like the fact that the tests we end up with using TDD give us additional leverage: they make it easier to change our code and know that it is still working without having to re-reason through the entirety of the code base."

  • "Quality is a function of thought and reflection - precise thought and reflection."

  1. Tests are supposed to enable "Refactoring Mercilessly"
  2. Code has to be structured in a certain way to be testable. That tends to drive designs towards loose coupling across internal boundaries around cohesive capabilities.

One caveat: Michael Feathers is a classicist (Detroit/Chicago style), not a mockist (London style); i.e.

"The problem that I saw with the mock object approach was that it only tested individual classes, not their interactions."

Which means overuse/abuse of mocks can undermine the beneficial design pressures that tests can bring to bear; typically mocks are OK for dependencies you don't control but a classicist would generally not mock code that is under their control.

Now people will often quote DHH's Test-induced design damage to support that TDD doesn't improve design. However that is from the perspective of a framework author. A framework (or library) imposes design pressures of it's own which often compete with those of the application domain.

With a framework a problem is always solved on the framework's terms somehow coercing the various application concerns in there. So TDD will always place frameworks (like Rails, React) with the Horrible Outside World.

Collapse
 
marcinwosinek profile image
Marcin Wosinek

Well said! Thanks for your comment.