> I don't think everything needs a comprehensive set of unit tests though.
There's a difference in the tests of that era though. Around the xp times, unit tests were for unit of functionality, not per-method.
There's a difference in the tests of that era though. Around the xp times, unit tests were for unit of functionality, not per-method.
“Unit tests are small tests, each one exercising a little piece of functionality. The units tested are usually individual methods, but sometimes clusters of methods or even whole objects.”
Extreme Programming Explained: Embrace Change, 2nd Edition (2004) Kent Beck
You said: “Around the xp times, unit tests were not per-method.”
Beck said: “Unit tests are usually individual methods”
Either that or tracing/logging/debugging, but other than specific niches like parsing (of specific bug repros) I think integration tests are generally a lot more bang for the buck.
Anyway, if you want to go down a related-but-unrelated rabbit hole, J.R. Thompson's lecture on the Space Shuttle Main Engines is a good one. You can probably watch it at higher speed to smooth out the many, many "uh"s (believe me, it's bad):
Integrated testing: https://youtu.be/uow6v1EuybE?t=1292
Test to failure: https://youtu.be/uow6v1EuybE?t=3135
https://ocw.mit.edu/courses/16-885j-aircraft-systems-enginee...
--
There's this more-modern link but in true modern fashion you can't really link to specific things presumably because it's all javascript muck: https://openlearninglibrary.mit.edu/courses/course-v1:MITx+1...