Re:Why I Hate Test Driven Development
by drostie on Tuesday May 29, 2012 @04:43AM
(#4036548)
My problem is more that I never know what to test. I mean, suppose I have some nontrivial code -- one of my latest random projects contains this:
It's a recursive generator-driven permutation engine. Technically I suppose the order of the permutations doesn't matter, so long as they are all distinct and there are n! of them. Is that what I should be testing? That is, should my test code read:
...? And if so, how does that help me write the original function? Or am I supposed to test a base case and one or two recursion steps, so that it helps me write the function, but "hard-wires" a particular order?
[ Parent
| on HN ]
You're right to want to avoid duplicating your code inside your test. In this case, I'd work out some simple permutations and test against those values, sorting the results so order doesn't matter.
assert(sorted(permute((1, 2))) == [(1, 2), (2, 1)])
Re:Why I Hate Test Driven Development
by yummyfajitas on Tuesday May 29, 2012 @08:19AM
(#4037081)
...so that it helps me write the function, but "hard-wires" a particular order?
Use assertItemsEqual.
http://docs.python.org/library/unittest.html#unittest.TestCa...
The way I do it:
In the doctest, I include a few toy examples, stuff I can verify by hand, and which helps the user understand what I'm doing.
In the unit tests, I try to do things in the style of Haskell's Quickcheck (the greatest testing library out there). Generate some random values and test properties (e.g., len(permute(x)) == factorial(len(x))).
Re:Why I Hate Test Driven Development
by blazingice on Tuesday May 29, 2012 @05:27AM
(#4036653)
You have a good point about TDD, and I'm unsure how to address it.
However, you might find the itertools library helpful, particularly itertools.permutations(): http://docs.python.org/library/itertools.html#itertools.perm...