On Wednesday, June 17, 2015 at 4:39:31 PM UTC-4, Marko Rauhamaa wrote:
> The way it was explained to me was that in TDD you actually don't write
> code to any requirements or design: you simply do the least to pass the
> tests. Thus, say you need to write a program that inputs a string and
> outputs the same string surrounded by parentheses (the requirement), the
> starting point might be this test case:
>
> - run the program
> - give it the word "hello" as input
> - check that the program prints out "(hello)"
>
> The right TDD thing would be to satisfy the test with this program:
>
> input()
> print("(hello)")
>
> That *ought* to be the first version of the program until further test
> cases are added that invalidate it.
The true TDD acolytes advocate a very idiosyncratic workflow, it's true.
I don't do this, but I also don't consider myself a TDD person. I value
tests a great deal, and put a lot of effort into them, but I don't write
trivial functions to get my tests to pass and then go back to change them.
But people whose opinion I value do advocate that, and it's possible that
in time I will understand their methods and use them myself. Stranger
things have happened...
--Ned.
--
https://mail.python.org/mailman/listinfo/python-list
