TDD is BS?

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Jun 20 07:46:29 PDT 2013


On 6/20/13 5:49 AM, Jacob Carlborg wrote:
> 1. You have a problem to solve
> 2. You think about how to solve the problem and how a design can look like
> 3. You come up with a design
> 4. Write a test according to the design
> 5. Write the implementation
> 6. Run the test to see that the implementation matches your design
> 7. Repeat 2-6 until satisfied

This is reasonable.

> Example, write a compiler:
>
> Problem: Lex string literals
>
> Test:
>
> auto code = `"asd"`;
> auto token = lex(code);
> assert(token.lexeme == code);
> assert(token.type == Type.stringLiteral);
>
> Implementation:
>
> Write the implementation to pass the above test.
>
> Token lex (string code)
> {
> return Token(code, Type.stringLiteral);
> }
>
> This is obviously a dummy implementation but it's enough to pass the
> test.

I dislike this. I've seen conference talks and such where the speakers 
present the inevitable throwaway implementation that is patently wrong 
but makes the first unittest pass. That mindset doesn't sit well with me 
at all. I don't see why I need to waste time writing tongue-in-cheek 
code that is nonsensical and will obviously be deleted next.


Andrei


More information about the Digitalmars-d mailing list