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