I discovered testing and TDD when I was in university. I was trying to find something that could improve my programming skills overall and not just my skills in a specific language or stack.
To cut a long story short, I had excellent results as my grades greatly improved across all programming subjects. It wasn't only due to TDD, but it played an important role.
Because of how well things went during university, I naturally used it and still use it in my professional life as a Front-end developer. And given that I'm able to keep my developer experience pretty stress free code-wise, I'd say that things have been going pretty well.
If I had to say why I find testing and testing as used in TDD so amazing is because of 2 things:
- It forces me to think before and while I write code. This makes me find holes in the requirements and opportunities to improve the code's design.
- _It gives me a development process that lets me stay focused on my task at hand, which makes me more productive and less stressed.
Although it can be frustrating at the beginning, my opinion on testing and TDD is pretty good, and I recommend people try it out.
What's your opinion on testing and TDD?
Oldest comments (39)
Pros
For me it's the best way to implement a feature, you simply implements slowly and with a lot of confidence.
And the mais reason that i like it, is that you tend to create the feature in the most readable way.
Completely agree!
I liked how you mentioned that it lets you implement something slowly and with lots of confidence. I think it clearly expresses the feeling of being in control of the code that TDD can give.
I use TDD semi-regularly in my hobby projects. I've also spent the last month getting my team's main tool set up with a proper test suite. It's more for regression tests than TDD, but I'm excited about it, all the same.
I would say my experience with TDD is fairly similar - my code is better, and I think about my designs in more detail before implementing. I don't usually implement all the tests up-front, but I'll write down a large number of test synopses, and then implement the most important ones (and come back after to fill in the edge cases, just to validate my work).
I use it all the time, based on the same two points you mentioned.
I love it when people say about TDD. I also love to use it. But I'm too lazy to do that😅
It really depends on a task, if I write something really easy, I will avoid testing at all, because I see no point at all, but if it is not the case, then It what gives me carefree attitude.
Breaking things and medium / long term maintenance are real risks. If I plan to maintain it, testing is a must.
I wouldn't do UI testing, though. I am just not convinced.
I haven't used testing in any of my projects in a 26 year professional career
That's interesting! How do you deal with regression issues when working in codebases with other people?
Having test cases is important and it's useful in a DevOps perspective due to reliance on automating the small stuff which includes creating testing pipelines to test your code without you running it yourself.
As for TDD, it depends on your company or organisation engineering practices. They might require you to do it and you can do it to affect yourself. Ideally, I would go for TDD and as others have mentioned it's really subjective. Since there will be a need to write code that requires you to get it out as soon as possible. Especially you are creating a prototype or MVP who has a very short timeline for it to be completed.
That's a great observation. A lot of developers don't know how to write tests and how to write testable code. I think that a lot of that has to do with the culture of the company they're in. Especially when we're talking about project-based companies, which tend to privilege shipping as soon as possible vs. reducing the cost of development on the medium to long term, it's a kind of environment that privileges hacks over a sustained practice, which makes testing and TDD hard to flourish. So it's unlikely for someone working in a situation like that to be given the time to learn or to have someone to teach them how to test/TDD. At least, that's my experience.
Yes, TDD is great, but only when it makes sense (i.e. don't make it into religion);
People certainly can take it too far and make it into a religion. Like it is some silver bullet that will solve all development problems when it won't. It's a technique that has its advantages and limitations, although I'd say it is one of the more useful ones I've come across. But I'm probably totally biased.
About point 2, I think it covers one of the limitations of TDD. TDD can never find an unexpected new bug in a system for a simple reason. We are the ones writing the tests, and that means that they are limited by our imagination. And, speaking for myself, we aren't very good at imagining all the ways our programs can break. We could try to stretch our imagination and write tons of tests, but then we end up with a codebase that's much harder to maintain than it needed to be. The way I found to deal with this issue is just to write enough tests to force me to implement a feature, and after the feature is "done" use exploratory testing to find bugs I didn't imagine could exist. And then write regression tests for those new-found bugs. It's been working great so far :)
I think item 1 does not consider the time spent on executing tests. When we work with software that keeps evolving during the time, writing tests makes you spend less time with tests then executing them manually every time.
There's a difference between an engineer and a hacker. One isn't better than the other, but have different values.
Applying an engineering approach to software development is impossible without test driven development, but sometimes hacking something together is where the value is.
You reminded me of a talk from Kent Beck . He expressed really well that idea that hacking and engineering can have important roles in development depending on which stage a project is at.
TDD: absolutely fantastic and valuable if you have the skills and discipline to use it. One of the most elusive phenomena in software engineering, something of a holy grail, many people say they want it, comparatively very few actually do it (or do it well, at least).
I don't follow TDD exactly, but for some things I do write some tests. It might not be a full on Unit Test that we are familiar with, but I usually do something to prove that what I wrote works.
The Pragmatic Programmer (book) nails it:
And:
Gotta love that book. It aged really well!
I like this perspective.
Indeed. But you really don't need to be doing TDD for 30 years (or at all) to get there
I have used TDD once and find it really useful and fun to learn. I was able to write my codes more organized and easier to understand. But the thing is were not using TDD, clients wants to get things done asap.