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