4 ms·

> YOUR code is hard to test BECAUSE you don’t TDD. TDD isn't dead, but it also isn't a silver bullet.

HeyLaughingBoy 12y ago
Exactly. What all this foaming at the mouth ignores is that it is very possible to do "TDD" and still accomplish nothing useful. I've seen tests that for all intents and purposes will never fail because they are testing the wrong thing. Write a huge method that has numerous side effects, but only test the return value? Essentially useless!
- MaulingMonkey 12y 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 12y ago
    I'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 12y ago
      There'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/

Exactly. What all this foaming at the mouth ignores is that it is very possible to do "TDD" and still accomplish nothing useful. I've seen tests that for all intents and purposes will never fail because they are testing the wrong thing. Write a huge method that has numerous side effects, but only test the return value? Essentially useless!

MaulingMonkey 12y 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 12y ago
  I'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 12y ago
    There'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/