🔍 Tests (don't) slow down development. v1 🔎

# [ $davids.sh ] · message #238

• @ [ $davids.sh ] · # 1418

  How tests speed up development:

  – I never run the code I write. Instead of deploying code locally and hitting it via Postman / Cli, I just need to write tests, and in 90% of cases, if the tests pass, everything will work.

  I don't know about you, but for me, manually verifying code I've just written is a very tedious process. When I've timed how long it takes me to manually check a feature, it often turns out to be longer than writing a test.

  It's even worse when, during verification, it turns out that nothing works. Then you have to set up debugging and hit the same endpoint dozens of times. With tests, it's much easier.

  – You can touch other people's code. Sooner or later, you'll have to go into a colleague's module/service and add something there. In a normal situation, besides understanding what your colleague wrote, you'll also have to figure out: "how do I correctly test that I haven't broken anything?" – and this check will take 2-3 times longer than the task itself.

  If your colleague has written tests, then at least they should pass, and you can add your own cases to them.

  – Fearless refactoring. And this is no joke: thanks to tests, I'm not afraid to take a piece of code that has already caused a lot of doubts or problems and just COMPLETELY rewrite it. Why? Because tests can at least give me a solid piece of confidence that the rewritten code will still solve previous tasks, and also handle new ones better.

  I don't know about you, but for me, the ability to refactor is a very strong boost to confidence in the project's reliability and enjoyment of working with it.

  – And the good old regression, or rather, its reduction. On absolutely all projects, we've very often encountered the problem of regression, where new code could affect old code in very strange ways (updated a library, added an independent plugin to an existing one, added a method to the logging system, etc.), meaning in places that seemed to be extended, not rewritten.

  While writing this, I realized something very interesting: all articles on the topic of "problems with tests" are very similar to articles on "problems with static typing." ** If you're the kind of person who, at one point, overcame the barrier of static typing and realized you never want to write anything without it again, then you'll have the exact same success story with tests; you just need to get past that barrier.**

  Therefore, my answer is this: there isn't a single case where having tests could negatively affect your productivity in any way.

  The only exception is: you don't know how to work with them effectively enough.

  But the most wonderful thing about this exception is that it's easily fixable, which I'll talk about next.

• @ Ivan ITK 🚫 · # 1419

  Overall, the entire post can be summarized by the term regression testing, which translates to weeks or months per year of work, depending on the release frequency, team size, and codebase.

  I would also add about API-first vs. code-first (TDD) approaches, noting that there are many approaches and tools for each. Describe OpenAPI and AsyncAPI once and get end-to-end tests as a bonus, and if you look further, you'll get mocks, SDKs, data models, and everything else.

• @ [ $davids.sh ] · # 1420

  api-first will be in the next post)

• @ Vassiliy ITK Kuzenkov · # 1421

  Oh, I'll add that if you get past the barrier with tests, then coming to dynamically typed languages afterward is also much easier on the soul. But unfortunately, I have an example from experience where the team wrote tests for absolutely everything and checked things that weren't necessary. That's where I first introduced property-based testing, and the enjoyment of tests immediately increased.