3 ms·
Indeed. There are plenty of things that are hard to usefully test. Multithreading code? Enjoy using TDD to ensure it has no livelocks, deadlocks, or missing
by MaulingMonkey 13y ago
Indeed. There are plenty of things that are hard to usefully test.
Multithreading code? Enjoy using TDD to ensure it has no livelocks, deadlocks, or missing memory barriers leading to reordered operations. Especially if it's inlined in multiple contexts...
Graphics code? Needs to look similar (but not necessarily exactly the same) across a wide range of OSes, underlying APIs, GPUs, and driver versions - plus many of the same concerns as multithreading code.
Cryptographic code? Well, perhaps heartbleed could've been caught ;). But all the well intentioned MD5 unit tests in the world won't make it useful (in-context)...
- hderms 13y agoI'm not a TDD adherent in any way, but depending on the language you can get some interesting results with automated tests and concurrency. Erlang has a number of applications which automatically reorder the scheduling of the various processes running in order to (hopefully) ensure the code doesn't die when run concurrently. This is much easier to do in certain languages (ruby obviously not being one of them). Then again, traditional livelocks, deadlocks and improper use of memory barriers aren't really the problems that you would face at the level of abstraction that Erlang provides.
- MaulingMonkey 13y agoThere's also tools like CHESS to do that kind of thing in Microsoft's ecosystems: http://research.microsoft.com/en-us/projects/chess/ http://research.microsoft.com/en-us/projects/chess/