4 ms·

I've seen a lot of silver bullet fads come & go. I'll be glad to see the TDD fad go. Testing sure is a useful tool in the toolbox, but that's it. It's funny th

by astangl 14y ago

I've seen a lot of silver bullet fads come & go. I'll be glad to see the TDD fad go. Testing sure is a useful tool in the toolbox, but that's it. It's funny this article quotes the asymptotic sort behavior, because that's almost identical to a real-world example I have used to debunk over-reliance on unit tests (AKA "false sense of security"). Back in the days when we still wrote our own sort functions, we were working on various QuickSort implementations. A popular optimization is to end with an insertion sort after a certain point. So your QuickSort can be completely broken, and the insertion sort at the end will still clean up the mess. Unit tests will typically just validate that the list is sorted correctly and completely miss the fact that the QuickSort itself is broken internally. Nobody has seen fit to comment on this example, so far. Another fad I'd like to see gone is "no comments". My mind still boggles from a recent code review where I had to defend using comments. Sure, we've all seen worthless comments, and misleading comments, but let's not throw the baby out with the bathwater and ban comments altogether! Self-documenting code is an ideal that should be aimed for whenever possible. But there's still a place for block comments in certain areas to explain key design and implementation decisions, tell a future maintainer what they might want to consider before changing or enhancing something, etc. It's not always possible to capture all that in code.

prophetjohn 14y ago
|A popular [quick sort] optimization is to end with an insertion sort What's so hard to test about this? If your quick sort code and your insertion sort code aren't all shoved into one function, you just test them separately.
kamaal 14y ago
Unit tests verify if what you have written is correct. They don't verify if you are writing the right thing. Writing unit tests for the wrong thing, only tests the wrong thing.
VikingCoder 14y ago
If you want it to work, you do 100% code reviews. Many people think they want it to work, but they don't want to put in the effort to make sure it works. When you do a code review, you demand what you think are reasonable tests. If the organization you work for supports your sincere belief that the code is fucked, and needs re-working... or the testing framework is fucked, and needs re-working... or the guy typing shitty code is fucked, and needs to not be working... then over time, your code will tend to get better. As long as you've got the relevant skills in the room. A sufficiently difficult problem is not likely to be coded correctly by someone who lacks the requisite skills and experience. It pretty much comes down to "invest in the code, or exploit the code." Many managers think they're investing in the code, just because they have coders adding features. That's like saying you know you're fixing potholes, because you see people driving on the road. NOTE: doing code reviews does not guarantee it will work. But over time, skipping code reviews guarantees it will eventually not work.
fadzlan 14y ago
It never was a silver bullet to begin with. There is no way that unit testing could cover every ground. Granted, for what its worth, it is something that is reasonably cheap that you could run over and over again cheaply. Functional testing can cover most of the cases, but its more costly, requiring a full system setup, takes longer time to run and more expensive to write. Manual testing seems straightforward, but its not repeatable, hence more expensive, since it requires warm bodies to run it every single time. Given the effectiveness and the cost of each approach, it makes more sense to have different coverage for different test. For something that is more expensive, you would choose to create and run it for the most important part of the system. For something that is dirt cheap, well, why not just run it everywhere? Consider regression test. It covers every part of the system. But its not possible to run it every single time a developer change something. The cost is too prohibitive to run it at every changes, even with automation, much less using the manual approach. What about unit test? Dirt cheap. You can run it every 15 minutes or so if you are inclined and it would still be okay. I would say that it is wrong to start a software development exercise and just religiously say we have use TDD. The right question to ask, is what is your of degree quality and what is the cost that you are willing to pay. For some people, hey, lets just hire rock star developers for everything, but some projects cannot afford that. And if can only afford a team that barely knows what unit testing is, there is not much point of training everyone for a short project (say, 3 months with 1 month warranty). And yeah, there is limited benefit with unit testing (as is with everything), but still I don't think its fair to throw the baby into the bathwater too soon either. Do what make sense and do what works.

by astangl 14y ago

prophetjohn 14y ago

|A popular [quick sort] optimization is to end with an insertion sort What's so hard to test about this? If your quick sort code and your insertion sort code aren't all shoved into one function, you just test them separately.

kamaal 14y ago

Unit tests verify if what you have written is correct. They don't verify if you are writing the right thing. Writing unit tests for the wrong thing, only tests the wrong thing.

VikingCoder 14y ago

If you want it to work, you do 100% code reviews. Many people think they want it to work, but they don't want to put in the effort to make sure it works. When you do a code review, you demand what you think are reasonable tests. If the organization you work for supports your sincere belief that the code is fucked, and needs re-working... or the testing framework is fucked, and needs re-working... or the guy typing shitty code is fucked, and needs to not be working... then over time, your code will tend to get better. As long as you've got the relevant skills in the room. A sufficiently difficult problem is not likely to be coded correctly by someone who lacks the requisite skills and experience. It pretty much comes down to "invest in the code, or exploit the code." Many managers think they're investing in the code, just because they have coders adding features. That's like saying you know you're fixing potholes, because you see people driving on the road. NOTE: doing code reviews does not guarantee it will work. But over time, skipping code reviews guarantees it will eventually not work.

fadzlan 14y ago

It never was a silver bullet to begin with. There is no way that unit testing could cover every ground. Granted, for what its worth, it is something that is reasonably cheap that you could run over and over again cheaply. Functional testing can cover most of the cases, but its more costly, requiring a full system setup, takes longer time to run and more expensive to write. Manual testing seems straightforward, but its not repeatable, hence more expensive, since it requires warm bodies to run it every single time. Given the effectiveness and the cost of each approach, it makes more sense to have different coverage for different test. For something that is more expensive, you would choose to create and run it for the most important part of the system. For something that is dirt cheap, well, why not just run it everywhere? Consider regression test. It covers every part of the system. But its not possible to run it every single time a developer change something. The cost is too prohibitive to run it at every changes, even with automation, much less using the manual approach. What about unit test? Dirt cheap. You can run it every 15 minutes or so if you are inclined and it would still be okay. I would say that it is wrong to start a software development exercise and just religiously say we have use TDD. The right question to ask, is what is your of degree quality and what is the cost that you are willing to pay. For some people, hey, lets just hire rock star developers for everything, but some projects cannot afford that. And if can only afford a team that barely knows what unit testing is, there is not much point of training everyone for a short project (say, 3 months with 1 month warranty). And yeah, there is limited benefit with unit testing (as is with everything), but still I don't think its fair to throw the baby into the bathwater too soon either. Do what make sense and do what works.