Giving up on test-first development
iansommerville.com
Giving up on test-first development
1–10 of 224 posts
Re: Giving up on test-first development
#2> I’m sure that TDD purists would say that I’m not doing it right so I’m not getting the real benefits of TDD.
"You are not doing it right! Take this 3-day course for a grand and buy these books. Also hire a TDD/Scrum/Agile coach for your team for a few months. There you go! (in Eric Cartman's voice)."
Re: Giving up on test-first development
#3"...because I think it encourages conservatism in programming, it encourages you to make design decisions that can be tested rather than the right decisions for the program users.." - Couldn't agree more with this.
Re: Giving up on test-first development
#4I've experienced very similar problems when experimenting with TDD. Really appreciate you sharing!
Re: Giving up on test-first development
#5From the article: Because you want to ensure that you always pass the majority of tests, you tend to think about this when you change and extend the program. You therefore are more reluctant to make large-scale changes that will lead to the failure of lots of tests. Psychologically, you become conservative to avoid breaking lots of tests.
Interesting. I've often found that the lack of tests leaves me absolutely terrified of making changes to large Ruby and JavaScript applications. I mean, if a test breaks, then I get a nice message right on the spot. But if I don't have tests, then the application itself breaks, and I may not find out until it's been put into production on a high-volume site or shipped to users.
Once an application crosses, say, 25,000 lines of code, it's hard to keep an entire program in my head, especially in a dynamic language and with multiple authors working on the code base. Under these conditions, large scale refactorings or framework upgrades can cause massive test failures, but the only alternative is to cause massive, unknown breakage.
Re: Giving up on test-first development
#6Like all things in life TDD should be taken in moderation.
It's an excellent process to create stable and maintainable code, but it does not fit every bill.
But abandoning it completely on the grounds that it sometimes makes you write "bad software" is a bit weird to me, in fact, one of the main arguments for TDD is that it makes you write better code.
I found that it does make you write better code many times. So like all things, use when appropriate.
I guess the real hard thing is to determine when using TDD is appropriate.
Re: Giving up on test-first development
#7I think the first and fourth points are applicable to unit tests in general rather than just TDD.
For the first point, I'm reluctant to make large-scale changes to code which doesn't have lots of unit tests because the unit tests give me confidence in what the behaviour of the system should be.
Certainly the third point is something I try to bear in mind when doing TDD. I've found that having someone do a code review after a feature is complete gives someone the opportunity to come in from that high level and look at the program as a whole and check that your design makes sense.
Re: Giving up on test-first development
#8TDD is nuts for code without a client or specification. The whole point of tests is to ensure that the code does what it's supposed to do. When you have neither client nor spec, how are you supposed to know what the code is supposed to do? There is, IME, a >90% chance that any such code will be ripped out and replaced as you develop a better understanding of the problem domain.
I've found it's pretty useful to go back and add tests as you accumulate users, though (or convince an exec that your project is Too Big To Fail in the corporate world). You're capturing your accumulated knowledge of the problem domain in executable form, so that when you try an alternate solution, you won't suddenly find out - the hard way - that it doesn't consider some case you fixed a couple years ago.
Re: Giving up on test-first development
#9From the article: Because you want to ensure that you always pass the majority of tests, you tend to think about this when you change and extend the program. You therefore are more reluctant to make large-scale changes that will lead to the failure of lots of tests. Psychologically, you become conservative to avoid breaking lots of tests. Interesting. I've often found that the lack of tests leaves me absolutely terri…
[deleted]
Re: Giving up on test-first development
#10From the article: Because you want to ensure that you always pass the majority of tests, you tend to think about this when you change and extend the program. You therefore are more reluctant to make large-scale changes that will lead to the failure of lots of tests. Psychologically, you become conservative to avoid breaking lots of tests. Interesting. I've often found that the lack of tests leaves me absolutely terri…
To be fair the author was abandoning TDD not tests.
He explictly said that he'll add tests after he writes the code.