3 ms·

Could you expand on this? Why are too many interconnected components or a complex AI algorithm a valid reason not to test or use test driven development? My v

Could you expand on this? Why are too many interconnected components or a complex AI algorithm a valid reason not to test or use test driven development? My view is that in a complex system, only by having confidence in the units can you have confidence in the integrated whole. You might be able to build a house that stands and looks nice, but if the timbers, the bricks, the foundations etc are all flawed in their own small ways, sooner or later those problems are going to combine and you will end up squashed. I can't think of a single example where automated testing couldn't potentially improve what you deliver and the process of working on it. Even the hackiest throwaway script could likely be produced faster and easier with a little automated driver.

plinkplonk 14y ago
"I can't think of a single example where automated testing couldn't potentially improve what you deliver and the process of working on it. Not engaging with the above argument, just trying to clarify an ambiguity. Just saying (and trying hard to keep tone neutral). automated testing != test driven development. The former has been in use for decades. The latter is a relatively new methodology/practice which emphasizes writing tests first and using tests to drive development.
CJefferson 14y ago
Oh, we certainly do massive automated testing. Our release testing script takes currently an 8-core machine about 4 days, and our nightly test runs on about 6 configurations, taking about 2 hours. However, often the units have properties which are very difficult to specify in isolation, and from experience almost all bugs come from many algorithms reading and writing the same data structure (I'm not thinking of threading issues here, although they are another issue). Consider something like a sudoku solver (the things I work on are much more complicated than that). Usually writing the function which checks the condition 'a row/column/box are all different' is very simple. The errors come when these functions interact, each effecting each other as they are called. Certainly, this kind of situation is very unusual. Most people write code which lends itself more naturally to test-driven development, and in those situations I approve of it.

plinkplonk 14y ago

"I can't think of a single example where automated testing couldn't potentially improve what you deliver and the process of working on it. Not engaging with the above argument, just trying to clarify an ambiguity. Just saying (and trying hard to keep tone neutral). automated testing != test driven development. The former has been in use for decades. The latter is a relatively new methodology/practice which emphasizes writing tests first and using tests to drive development.

CJefferson 14y ago

Oh, we certainly do massive automated testing. Our release testing script takes currently an 8-core machine about 4 days, and our nightly test runs on about 6 configurations, taking about 2 hours. However, often the units have properties which are very difficult to specify in isolation, and from experience almost all bugs come from many algorithms reading and writing the same data structure (I'm not thinking of threading issues here, although they are another issue). Consider something like a sudoku solver (the things I work on are much more complicated than that). Usually writing the function which checks the condition 'a row/column/box are all different' is very simple. The errors come when these functions interact, each effecting each other as they are called. Certainly, this kind of situation is very unusual. Most people write code which lends itself more naturally to test-driven development, and in those situations I approve of it.