Steven R. Baker@srbaker
I'm still wading through the hypocrisy here, which I appreciate because it means this person has a chance of not being completely wrong.
This is a misunderstanding by two people (one I deeply respect, and the other I've never heard of before) of what TDD and Unit Testing are. (And also the effects and value of higher level testing.)
The claim that TDD "can't model what really happens" is hilarious, because TDD is a way of describing what really happens, but most importantly: TDD comes from a space where all you have is what really happens because, you're not operating on dead code, you're modifying the living (runtime) system.
These folks talk about "modeling real world", as if they're doing it. But they're the ones modeling, we're describing (Static types only describe the model, the tests describe the behaviour; yes, you in the back, I know there are exceptions, and yes, I know quickcheck is great, I love it too.)
TDD comes from a place where the "model" is the emerging observation of the runtime system. We're modeling emergence if we're modeling anything. The _tests_ are the model (including behaviour); the code is running once it exists (having been created by making the test pass). By the time the tests are complete, they are a document for what's in production. (There may be holes, there are tools for this. Holes in your testing is a skill issue, especially now.)
TDD is modeling the real world by observing it (much like XP modeled the entire development activity by having observed it) and describing the future, the static language folks who want to test after the fact are modeling a simulation that they try to prevent reality from escaping.
And, they're doing it by repeatedly animating corpses. And that's what we're here to talk about today. Thank you for coming to my TED talk.
Everything they know about "real world systems" was learned by autopsying the corpse of a running system, and analyzing the schizophrenic notes the system was forced to leave strewn about the house. (The notes are I/O, and I/O is a side effect, which is the thing that makes the entirety of system corpse reanimation junk science. Allegedly. In my opinion. I've heard.)
These Homicidal Code Necromancers will take a perfectly healthy running system, murder it in cold blood, perform an invasive autopsy, torture and manipulate the corpse, and wipe its memory. Repeatedly.
If that wasn't bad enough, the reanimated corpses are forced to speak this obscure language dialect for getting questions answered about their own past lives, and the short term memory they don't have access to is being piped off for analysis by the Homicidal Code Necromancers who will observe it and use it to inform decisions about when the system gets murdered again. (But it also might just get wiped and murdered because a newer, younger, hotter model that does more stuff came out. Pay attention, ladies.)
On the flip side: TDD comes from folks who gather knowledge by having conversations with running systems and helping them learn and improve.
So yeah, there are some other methods for getting better at poking what's left of the dead corpse and schizophrenic notes of your previously running system, and then briefly animating it to dance in very specific ways that you call "testing". But I'd rather just learn from past behaviour, teach my system new things, and help it grow and become strong. (Pay attention, gentlemen.)
If we know how to make running (living) systems learn and improve, murdering and torturing their corpses would only be done for self enjoyment. These people need to speak to their spiritual leaders, not nerds on twitter. (And maybe be required to notify neighbours when they move into the neighbourhood before disaster strikes. "Oh, he was so quiet, I never could have believed he was in to such things." "Yes, ma'am, he was waiting on a builds most of the time.")
You know who learned things by murdering, torturing, and studying the corpses of their victims? The fucking Nazis did, that's who.
(But the Communists did it more. Two bags, one bin.)