When I'm navigating on the big wide web that is the internet I often see job postings that require experience in TDD. I've been programming for about two years and I've never really used PHPunit(shame) because each time I finish a functionality I test it with various inputs to correct bugs. Can someone explain (like I'm five) what's the importance of programming using TDD?
P.S.: I hope I've posted this in the right place cause this is my first time :p
Top comments (21)
Just went to a great talk last night on TDD by John Reese. His example helped me understand that, like others have said, writing the tests first helps write cleaner code that's easier to maintain, understand, and is obviously testable.
I think it's the backwards approach to what most teams are used to, but usually is a goal that they want to try, but just haven't made the switch.
Initial investment is a little deeper, which project management also isn't on board with generally, so that could be a factor as well.
By chance the talk isn't available online? A quick google search only revealed the meetup page and the next result was the actor of Person of Interest xp
The idea of writing the tests first does sound like it will help to building more robust code, have to try it soon if I get some free time
It’s not, he’s active in the open source community and the code is on github if you want to probe through it.
github.com/jpreese/MessageSender
I do TDD sometimes but it's never been my only way of coding, for me it just doesn't always fit the problem practically. But if I have a really good idea heading in of what I want the solution to look like and where the interfaces are going to be, it's a great way to step through your code and proactively sturdy it up.
I'll add that TDD is a bit like going to the gym, lots of folks have a membership, but most don't go as much as they say they do. TDD is a very disciplined way of coding and in truth it's not actually that popular, even among those who claim they do it.
I tend to take the opposite approach. The more unsure I am, the more I leverage TDD. Writing tests first really helps me think about structure, interfaces, etc.
I wrote a blog about this quite a few years ago: coveros.com/why-i-write-tests-first/
I like test-driven development, but I’m not a purist. I almost always write my code with testing in mind, but I don’t always write tests first. Most of the time, but not always.
When I do write the tests first, I find that the process works just like the books say it should. That is, I write the tests and in doing so define the interface that I want to use. By the time I have what I believe to be a complete, failing test, I have identified the behavior I want along with a number of edge cases. Once I start the implementation, coding is fairly straightforward and is usually done more quickly than I would have expected.
In my experience, I've found that many people and companies conflate and/or confuse TDD with unit testing in general. If someone asks me if I do TDD, I say no and then quickly explain that I'm less interested in when the tests are written - as long as they are written.
I've worked with a few people who always write the tests first. But the vast majority (90%+) tend to write tests during or after their code (or not at all!)
Totally agree. I also think "TDD" is often used to mean "Unit tests". Saying that you never unit tested your code during a job interview sounds a bit like suicide to me. On the other hand, I think no one will think it's a real problem if you code first and then unit test it.
Yeah, I also think that when most companies mention TDD they mean unit testing. In my current job I have practically zero at all to write tests as the main focus of the superiors is to get the most amount of results in the least amount of time possible...
There has been a heated debate on whether TDD is good practice or a bad pratice, with valid arguments on both sides (in my opinion).
There is a lot less disagreement whether "Self testing code", as Martin Fowler calls it, is a good thing: martinfowler.com/bliki/SelfTesting...
Spoiler alert: For any non-trivial project, it's a good idea, in my experience. Without it, you can't be sure that you didn't accidentally introduce errors in your software when making changes to the code.
Ever heard of "never change a running system"? That's a sympton of code that is not self testing.
Especially if you are developing in an iterative fashion, regression testing ALL of the code (not just the new features) every iteration is not feasible manually. At least not with reliable results.
But regression testing is exactly what you need to do to prevent unexpected side effects (apart from a design that reduces coupling). A new feature may break an old feature unexpectedly. Or what about that accidental typo you introduced without noticing?
TDD is one practice to lead you to self-testing code.
Some people claim it helps you with the software design, but I would claim you need to know about software design in order for TDD to help you with it.
I've attempted TDD a few times now in my hobby node.js development projects. I think the biggest thing you find is that when you start a new project you just want to get on and start coding. Pulling in the libraries you need and hacking away through the code.
However, whilst I know I'm a horrible person for doing the above, I do it all too often where time and fun is paramount working on these hobby projects you tend to want to forget the boring test world. With that being said, my current project has hit a point where there's some logic I know I simply need to test. For this specific logic I've produced my test file, added in some cases and I enjoy seeing the code re-run every time I save my work assuring me everything is ok.
There is enjoyment in testing. However, I don't feel like I have the enjoyment in writing a test for every single part of my code. In fact, I know that I struggle with gauging how in depth my scenarios need to be and also how detailed I need to go into the depth of my code to assure myself that everything is working OK. I believe I work in a world where I make a judgement as to how long I'm spending killing myself refactoring, re-running snippets of code and then where an automated test would pay off.
Testing is tough for my mind. As mentioned the level of detail required boggles me and also what about all those scenarios I may invariably miss? I understand the need, I do minimal testing but the world needs to stop making me feel guilty for my lack of 100% coverage.
I'll be posting a new thread soon in the hope to get some answers around some of these questions.
I'd like to separate out two things.
First, many job postings ask for TDD. Most companies want people who know it, but they will NOT do it. So knowing and speaking intelligently is going to cover a huge amount of job postings. It is often sought because some of the most well-known people in our field use it and have written about it extensively. It is also one of those things that are labeled a, "Best practice."
Second, TDD is a skill. It takes dedication and practice just like any skill. I've been doing TDD near exclusively for about 5 years now.
The benefits that I have seen come with it are:
I wrote an article here about trying TDD out
Short answer: It's not, because people are lazy.
But it does not mean you should stop doing it, or that you should never try it.
TDD for me is like healthy-eating habits: It's good for you in the long run, and makes you think before every step. And hey, because "not so many people eat healthy", Would you eat fast food on a daily basis? :P
Personally, I do some TDD, specially on projects that have lots of different inputs and complex rules.
PROTIP: If you use Visual Studio, you can enable Live Unit Testing, which is new for VS2017 and amazing for this kind of approach.
I use TDD at work for bug fix tickets specifically. This seems to mesh nicely with the way my brain approaches code. When I'm adding a feature, I often mess around a lot before I can really articulate to myself exactly what I am trying to do. Whereas with bug fixes, writing tests often helps me identify exactly what the problem is.
It's been a while since I did a refactor-only ticket as opposed to rolling refactors into some other work, but it seems like the TDD approach would be good for refactors as well.
Explained to a 15-yrs old: In most companies, and most groups, there's at least one or two people who use this practice on a daily basis. There's about as many people that haven't mastered the practice, ie they're not able to use it, most commonly due to lack of training and exposure.
Nope, in the programming world you have legacy code. Is not that used.
Automatic testing yes, TDD practice no. Also it doesn't make sense in startups, prototyping, MVP's, gaming and other fast changing envs.