Here's the truth about TDD (Test Driven Development). It's a broken practice. It's always been broken. It's broken by the definition of it. Its biggest merit is the encouragement of testing but that's about where it ends. TDD implies writing tests before writing the code. So, what's broken about this, Artem? You write tests to describe the intention behind the system—how you expect it to behave. TDD heavily implies that you should know how the system behaves before even implementing it. You should know what you're doing. Most of the time you don't. All the developers I know don't know that ahead of time. I don't know that ahead of time. In fact, I can spend days experimenting, writing an MVP, until I even begin to grasp what parts of my system should be and what I expect from them. I don't see TDD as a viable approach in fast-evolving systems, like the web. It may make significantly more sense when writing systematic software where very little changes from project to project. That's the complete opposite of what you write on the web. The negative aspect of TDD is that I've seen teams discouraged if they fail to follow it. And so they give up on the whole idea of testing since TDD is so universally associated with it. Instead of encouraging people to test and showing them that testing software can be fun, the practice locks them in pedantic constraints that no engineer can follow. I don't follow TDD. It doesn't mean I don't write tests. I write a lot of tests. What I do is Prototype-Iterate-Test development. Prototype. I give my ideas some room and let them breathe without caring too much about testing at first. I experiment, move things, break things, put myself in my user's shoes and design the API, behaviors, and expectations. As I said, this can take some time. Iterate. I take that time to make sure my system makes sense and satisfies the requirements toward it (which, by themselves, may evolve and change why I do this). Test. Finally, I write the tests. It's become an inseparable part of my workflow. I cannot imagine not writing tests. There are exceptions, of course. If I'm writing a simple I/O function, it doesn't need a day of work to understand what it does because that's all it will ever do. I may write some unit tests for it from the start. But the majority of my (and I'm sure yours too) work are not simple functions. It's complex logic that takes time to get right. If I follow TDD faithfully, I will be wasting my time writing tests that I will, eventually, throw away. Those are not useful and they'd help me not to gain confidence in what I'm building. Don't be discouraged. Adopt the practices that work for you (even if it's TDD, as long as you are not lying to yourself!). The important thing is that testing matters. It always did. Developers have been testing software since the 80s, I believe. You should too! I will do my best to show you that testing can be accessible and fun.