My corporate policy regarding unit tests

@rEaL-jAsE are u trolling? :Thinking:

@rEaL-jAsE the best in details this book will explain.

But if to say shortly... Unit tests serve us as

1) a way to be refactoring the code without any fear. We aren't afraid that something is going to break, because there tests will show, and if not, then highly likely everything is alright

2) if something breaks in the program, unit tests are superior alternative to debugging. Because if it is already covered, the tests already localize where is there source of problem, what was broken.

3) we launch tests before doing anything in commit and after added new functionality. We don't need to check manually that all of the application works right. Auto tests check everything in short moment.

4) tests serve us as auto-validated documentation, they describe and test all of the important functionality anyway

5) tests force us to write better code / architecture. If it is testable code, then it is already better

6) tests allow to develop further in big code base with lesser speed loss.

@darkwind "Having trouble with code quality? Write a lot of tests. And I mean a *lot*. Test every file in isolation. Mock as many imports as possible.

When you're done, your code will still be bad, but now your tests will make sure it's impossible to improve anything in any meaningful way."

@kiki it sounds like a plan. xD
Just kidding.

I am in the process of learning clean architecture at the moment. Trying to find the way of doing better. Hopefully I will.

@kiki and btw, as long as tests check just external behaviour of things, treat objects as black boxes, with checking just correct output for some input, then your mentioned problem is almost not valid ;b
The code is almost not attached to implemention details then.

@darkwind lol, another one learns "clean architecture" from bob martin. Good luck with that.

I consider him and his doctrine to be absolutely the most harmful thing ever done to the field of software engineering.

@kiki in one week I am going to start Code compete by McConnel, perhaps it will go better

@darkwind lol, and the code complete is probably the best book to turn an aspiring student into a hireable junior / middle software engineer. Excellent choice

@darkwind it’s not always interfaces. If you just test interfaces, you’re locking yourself within your initial architecture. Should the need arise to catch up with evolving business, it will be really really hard if you need an architectural leap. And you will need it, as you can’t just account for _everything_ in your initial architecture.

If you decide to go lower and just test small pure functions, it’ll be more time consuming than just hard typing. In fact, I never write tests as I rely on strict data models and types, and it’s just enough.

You have to decide your testing quantum. Is it one small pure function? Is it a class? Is it a business logic module like a screen in a web app? And for all quanta, I see no use for unit testing given you develop a product.

If you’re an outsource that fixes legacy or employs 400 junior devs, tests will come in handy. But that’s not the area I’m interested in.

@kiki I also found Head First Design Patterns book as super nice to go through. Quite pleasant memories about the book.

@kiki I can't believe that no tests can be justified for any program larger than 20 code lines. I just can't believe it.

I felt the impact of tests on my development process... and I don't think that lack of tests can be justified for any implemented architecture.

The smallest amount of it for REST API, at least checking that endpoints accept inputs and outputs correctly. At least those the most `external` tests should exist. Considering that those tests don't know how the code is written inside, refactoring should be pretty easy.

@darkwind man, in 2018 I implemented the whole startup in Clojure. A product of medium-ish complexity, six months, zero automated tests.

Three bugs.

@darkwind testing just endpoints is too large of a quantum to have any meaningful difference over just using hard static typing