(There's also a video if you prefer that.)
By follow TDD, I mean to follow the development cycle TDD promotes.
Do you think it is worth doing? Let's discuss .
Hi, About TDD I have few points to mention. first is that in my opinion, TDD is very suitable solution for REST API's servers, and it will be a little complicated in front-end development. I can say 99% of the times I'm not following this approach because it's time taking. and I'm not sure that why developer has to be involved this much of testing stuff, Developer do it's unit & sanity tests on it's own side and that will be enough for developer, more than this developer time is waisting. And Inside the teams with high pressure of work load, they never use this and some time they pass the sanity test also to QC team. Totally It's great to follow TDD, anything has a cost. and this one in cases cost time more that save it. cheers.
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.
Sébastien Portebois
Software architect at Ubisoft
I do follow it (almost every time) for bug fixes: first write the test which repro the bug....
But for new development, I try to be tdd-ish, depending on the use case, but definitely not by the book, and on purpose.
Rather than writing a long comment, I’ll quote John Ousterhout (Philosophy of Software Design, chapter 19.3 about unit tests:
And that’s it. If we follow TDD: we should stop as soon as we get working code. On the other hand, I believe working code is not enough when you strive to build good design (this is even the whole chapter 3 of John O’s book mentioned above: Working code is not enough, tactical vs strategical programming, and one of the 15th design principles he lists.)