About a start-up trap, or Robert Martin wants to harm us
I felt that the foundations of the universe were shocked when hundreds of habrauys began to furiously argue about the Robert Martin note about the startup trap .
Want to know how I usually participate in such disputes?
- So what kind of tests do you write yourself?
- Mne-e ...
')
- When do you write tests?
- Mne-e ...
- Do you even write tests?
- Mne-e ...
Okay, of course, I write tests, I just do not participate in such disputes. The times when we were all forced to take a TDD pill, drew a line between those programmers who loved tests with all their hearts and those who really didn’t really like writing tests. And getting involved in a dispute between these two camps is an excellent reason to lose a couple of hours in vain, instead of doing your job.
But right now I think I have this couple of hours.
The classic TDD, the one that says that the tests "should not know anything" about the implementation, about the real code - died, the train left, it's over. But undoubtedly, his short presence produced the expected effect - everyone thought about the code that was already written and thought about writing tests for it, so that when changing the code in the future, there were no problems.
Problems.
It is important. Problems. Repeat again - Problems. If you feel uncomfortable, let's solve these problems.
Listening to problems is the only reasonable way to go when developing software. One extreme - Rob Martin - will lead you into the deep jungle. The other - those who urge you not to think about dangers at all - will most likely lead you to failure. The idea that tests are just a waste of time is very dangerous, especially if this thought takes root in your mind. But the idea of ​​the absolute importance of TDD is no less dangerous.
When you write on a classic TDD, you lose most of your customer’s money, but if you don’t write tests at all, then you have to spend all that time again - in the future.
Classic TDD is an excellent theoretical technique that you can play with in your free time or on weekends. Classic TDD is an excellent marketing slogan if you are one of the trainers or a TDD coach. Yes, TDD is an item that is always looked at when applying for a job, but TDD is usually not the way an excellent application goes, made on time.
So what kind of tests do you still write?
Total
There are two types of pragmatists when it comes to testing. Those who talk about pragmatism, so as not to do the right things, and I.
Want to know how I usually participate in such disputes?
- So what kind of tests do you write yourself?
- Mne-e ...
')
- When do you write tests?
- Mne-e ...
- Do you even write tests?
- Mne-e ...
Okay, of course, I write tests, I just do not participate in such disputes. The times when we were all forced to take a TDD pill, drew a line between those programmers who loved tests with all their hearts and those who really didn’t really like writing tests. And getting involved in a dispute between these two camps is an excellent reason to lose a couple of hours in vain, instead of doing your job.
But right now I think I have this couple of hours.
The classic TDD, the one that says that the tests "should not know anything" about the implementation, about the real code - died, the train left, it's over. But undoubtedly, his short presence produced the expected effect - everyone thought about the code that was already written and thought about writing tests for it, so that when changing the code in the future, there were no problems.
Problems.
It is important. Problems. Repeat again - Problems. If you feel uncomfortable, let's solve these problems.
- Do you have a lot of tests that have to be removed if any feature was unnecessary? Well, do not write so many of them - you are probably experimenting with the product, and perhaps the “explore and stabilize” approach will suit you better.
- Is it difficult for you to make changes to the code, because at the same time everything breaks down and the components are very strongly connected? Write a few tests on this subsystem, try the test-first approach when writing new code, and problems with strong connectivity will be solved.
- You have to dance with a tambourine around a little feature, because you are aiming for the thinnest unit testing, which means that you have to add tons of code where simple CRUD operations would suffice? Stop, think about integration testing and using in-memory database to speed up tests.
Listening to problems is the only reasonable way to go when developing software. One extreme - Rob Martin - will lead you into the deep jungle. The other - those who urge you not to think about dangers at all - will most likely lead you to failure. The idea that tests are just a waste of time is very dangerous, especially if this thought takes root in your mind. But the idea of ​​the absolute importance of TDD is no less dangerous.
When you write on a classic TDD, you lose most of your customer’s money, but if you don’t write tests at all, then you have to spend all that time again - in the future.
Classic TDD is an excellent theoretical technique that you can play with in your free time or on weekends. Classic TDD is an excellent marketing slogan if you are one of the trainers or a TDD coach. Yes, TDD is an item that is always looked at when applying for a job, but TDD is usually not the way an excellent application goes, made on time.
So what kind of tests do you still write?
- I usually use the “explore and stabilize” approach for those features that may eventually be excluded from the final product. Thus, I do not spend time on tests earlier than necessary, and get feedback on new features as quickly as possible.
- I usually start with integration tests, replacing all the slow parts with their memory-driven representations (for example, replacing a database with an in-memory database in tests).
- I go down to the level of unit tests, if I see complex logic (oddly enough, most systems are regular CRUD, so this is not necessary)
- Usage scenarios are usually checked using the UI as part of the acceptance tests, since this is exactly what the user sees.
Total
There are two types of pragmatists when it comes to testing. Those who talk about pragmatism, so as not to do the right things, and I.
From the translator: Rob Ashton is a well-known freelance developer from Europe who participates in many open-source projects.
Source: https://habr.com/ru/post/172039/
All Articles