Splitting of string at an interval

Roy Smith roy at panix.com
Mon Apr 8 11:37:28 EDT 2013


On Apr 8, 2013, at 11:10 AM, Arnaud Delobelle wrote:

> On 8 April 2013 14:21, Roy Smith <roy at 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
roy at panix.com




More information about the Python-list mailing list