How to learn Test Driven Development instead of Test First Development?

Question

Software testing

Hello. My name is Igor and I am an alcoholic and I have had problems with TDD for more than a year. Like many other developers who have problems with TDD, I constantly make the same mistakes:
- Naive Test First approach. Instead of writing a unit test in parallel to the code being tested with a one-step difference, I often write a test suite for a method, and then the implementation of the method itself. It's not TDD, it's Test First. Muck.
I take more in a spoon than I can chew at a time. Like this? Very simple. Sometimes I write a unit test for a whole class at once, and not for a method. Pervert? Well, it looks better from the outside.
“I just can’t see much sense in such a perverted TDD. I can apply Invertion of Control only at the moment when the need for it is revealed, and not when it is necessary to design types.
- I'm breaking down. Yes, all of us who do it wrong will quit sooner or later because it is unbearable. There is almost no point in Test First (sorry for being harsh).
Questions:
- So how do you learn the right TDD, which gives blossoms, smells sweet and bears fruit? Are there sensible guides somewhere , or rather large enough practical examples and tasks aimed specifically at teaching this business?
- What other typical mistakes, in your opinion, are there when trying to do TDD?
Thank you very much. With hope for healing, Igor.

Answer 1

I also sometimes use the approach you describe - and it does not seem bad or pointless to me. Very often it turns out to be effective - for example, when you need to write integration tests for ready-made functionality.
I think you can easily find materials - they are heaps on this topic.
In my opinion, the most important thing is that TDD requires a special approach to thinking while writing code. And it is this approach that makes it effective. It lies in the fact that you are not trying to completely build in your head a working method that you create. Instead, you highlight the individual business components of the method - and create them in stages.
The profit is that a person does not have enough intelligence to cover the entire business of even a fairly simple method (although he thinks otherwise, of course) - hence there are problems with further support of the method, bugs, overcomplicated methods, code that has low or zero business value, etc. d.
For example, you make a method that calculates the root of a number ... Write a simple test by feeding the number 4 there and expecting the output to be 2. Next, implement the functionality to ensure that the test passes.
But there is nothing more to write there. Then write the following test, for example, for a reaction to negative values ​​- then implement the functionality. Etc.
That is, it is a method of thinking. You won’t be able to come to this yourself - the best option is to hire a person who already knows how to do this and learn by sitting with him in a pair. If this is not possible - try to understand the style of such coding using tutorials on real situations like this .
Here are the problems when using the approach.
TDD is not a testing method, but a development method. It requires architectural readiness of the system.
When testing a module (such as a method or class), be sure to get rid of all external dependencies by mocking.
It is better to introduce this as a strict rule - because you can leave such dependencies only in rare cases and when you are already familiar with the topic and know what is called - where the rules can be violated.
Do not be lazy to develop according to the pattern - following the smallest and even the strangest rules - even if you see a loss in efficiency - and over time you will learn how to use this tool.