Do you do & follow TDD?

View other answers to this thread

Learn Something New Everyday,
Connect With The Best Developers!

Sign Up Now!

& 500k+ others use Hashnode actively.

Gaponenko Andrei's photo

I wish I could say that "Yes I follow TDD" and leave it at that. But since we try to have an honest discussion here and the topic is really interesting for me as well, I feel like some additional information should be provided.

First of all, I do try to follow TDD/BDD/(whatever the new shiny word it is now) whenever it's possible. The concept itself is very nice. It's all about systematic approach and being consistent as much as possible even if sometimes it feels like it takes more time to produce satisfying result and sometimes it does take more time. But being consistent is nice and often I find it much easier to develop in this incremental way.

Now the "problem" is: we don't have unit tests for every component. Or is it a problem in the first place? Frankly speaking: I have no idea. But the more experience I get the more I find that being dogmatic about something is often not viable approach. A lot of code is written to work with different kinds of data sources (DB, Elastic Search, JMS, etc.) and very often I find it impossible to find time to write unit tests for that kind of integration logic. Not even sure you need unit tests for it, as integration tests would do a better job. Especially if you work with a codebase that changes very quickly, like in a startup environment. It's just that people responsible for the business side of the project always want new features and it's already very difficult to squeeze in something tech-related (e.g. refactoring) as it is.

On the other hand, when I feel that logic is worth to be tested and it's possible to do now, within reasonable amount of time, I try to follow TDD cycle. The result is not always as good as I want it to be and it sometimes it does take more time than "tests after" approach and especially "no tests at all" approach.

It may be just the lack of experience on my side, really. Perhaps I have yet to understand the brilliance of TDD in it's absolute form or something. But then, I've never even had a chance to work with people who even try this approach, much less encouraged it - there was no one to show me the ropes. At the end of the day, I think that unless your team already follows TDD and has established practices including those for time estimation, it looks impossible for me to follow TDD even 90% of the time.

slim's photo

Fullstack javascript developer

TDD is a good approach that facilitates the design of your function or api but it is hard to use it when the project design is complicated and there are a lot of dependencies that you need to mock or when the project does not respect some best practices. I struggle with this issue when I work in a new project where team members don't give importance to tests. They just did some to pass the build pipeline.

Want to read more?

Browse featured discussions

© 2020 · Hashnode