On Apr 8, 2013, at 11:10 AM, Arnaud Delobelle wrote: > On 8 April 2013 14:21, Roy Smith <r...@panix.com> wrote: > >> For a while, I was rabidly(*) into TDD (Test Driven Development). The >> cycle I was using was, "Write a specification of a behavior, write a >> (failing) test for that behavior, then write the least possible amount >> of code to make the test pass. Lather, Rinse, Repeat, Ship" >> >> The "least possible" part is important. It makes sure the cycles stay >> short (ideally, just a few minutes), and that you don't write any code >> for which you don't have tests. > > The least amount of code is often also not the best in terms of time > or space complexity. Does this mean you have to write tests for time > and space complexity as well? That's interesting, but I don't know of > tools to help do that (time complexity seems easy enough, but space > complexity seems tougher to me).
If space and time complexity are important, then you need to write a test for those things. If you have no test for them, then it's not important and you shouldn't worry about it. At least according to the TDD catechism :-) >From a somewhat less radical point of view, the first thing you want to do is >get the code to produce correct results. Once you've got that (and a fully >comprehensive test suite to prove it), then you can move on to making it more >efficient, and your test suite serves as protection against behavior >regressions. And, yes, I agree that testing for time and space complexity are not trivial, because making accurate, repeatable, and isolated measurements of those things is often surprisingly complicated. I can't help point out, however, that if your initial implementation is to have your code return a constant, it's pretty likely to be an optimum solution in both time and space :-) --- Roy Smith r...@panix.com -- http://mail.python.org/mailman/listinfo/python-list
