3 ms·
> If I suck at writing code there's no reason to believe I wouldn't suck at writing tests to check that code. Actually, there is ; providing the difficulty is
by Ace17 9y ago
> If I suck at writing code there's no reason to believe I wouldn't suck at writing tests to check that code.
Actually, there is ; providing the difficulty is algorithmic.
Take "sort", for example.
// test code
assertEquals([1,2,3,4,5], sort([4, 1, 2, 3, 5]))
// production code
int[] mySort(int[] list)
{
// TODO: implement a sorting algorithm here.
}
Any programmer could write a fairly good test suite for "sort".
However, I highly doubt they could write the implementation.
Of course, this is a very simple example.
Most of the times, the difficulty lies in finding the proper interface between test and production code.
And there, there's no way to compensate for poor software design skills.
Actually, forcing bad software designers to test the code they write might even worsen the situation, by rigidifying poorly-designed-wannabe-interfaces.
> this idea that TDD is a panacea where no bugs ever survive didn't ever make sense to me in the first place.
This is the software industry ; new techniques are confused with silver bullets!
- strictnein 9y ago> "Any programmer could write a fairly good test suite for "sort". However, I highly doubt they could write the implementation." I mean, any developer should be able to write a sort. They might end up with some O(2^n) behemoth, but they should be able to do it.
- bluGill 9y agoAny developer should know the basic algorithms. If you tell one to write sort they should immediately think to look up merge sort is implemented. My algorithm will be O(n ln n), not because I'm great at creating algorithms but because I know I can do better.