On 30/05/07, Chris Foote <[EMAIL PROTECTED]> wrote: > I've toyed with PyUnit a little bit (http://pyunit.sourceforge.net) > but I don't really understand test driven development. > > To me it seems like you'd spend far too much extra time getting your code > to fit the tests than getting real work done, especially with projects > than involve lots of external components like databases, distributed > procedures and actions that take place in the background using threads. > Maybe I'm missing a big piece of the testing puzzle :-( > > Having code not break when getting modified by herds of software engineers > would have to be a good reason to use it, but aren't its benefits very > limited for one or two man projects ?
Well, I'd say no :-) Your tests also define your requirements in a far more concrete way than any externally developed and updated spec. While the code might be the definitive definition of what your software does, the tests document implicit behavior, moving that behaviour to become an explicit requirement, and hence persistent through subsequent modification (even by yourself - who can remember the code they wrote last month? Or even last _week_!?!?) I'd also say that TDD also encourages you to only write the code you need to. Far too often we're asked to build a rope bridge over a ravine, and instead we build a harbor bridge :) TDD makes us think about what we're building. TDD encourages us to write code that is testable - meaning that when a critical bug does come in, you don't have to resort to a debugger - it's going to be more likely to be able to write a test to catch that heisenbug (corollary: Having unit tests for a multi-threaded system is far better than trying to use a debugger in a multi-threaded system) TDD also improves your productivity - since you're not trying to come up with the grand unified theory of everything, but rather writing only enough code to satisfy the next test, you get more done. The demotivation of hard problems is dissolved into small tests with small solutions. Regarding the problem of interfacing to external databases and network resources, making use of mock objects can alleviate this. It's still more work, but helps us to solidify interfaces and understand the problem better. Eat your greens, they're good for you :) Of course, TDD is much easier when starting a project from scratch. I have a 30KSLOC non-python code base right now where we're trying to retrofit unit tests and implement TDD practices going forward. Let's say it's not fun[1]. But we're already experienced some benefits - refactoring has been easier than expected for adding new functionality. So to summarise, I'm a convert. It's TDD for me! Michael... [1] But the testing framework is partially in Python, so there's _some_ fun :-) -- Michael Davies "Do what you think is interesting, do somthing that [EMAIL PROTECTED] you think is fun and worthwhile, because otherwise http://michaeldavies.org you won't do it well anyway." -- Brian Kernighan _______________________________________________ sapug mailing list [email protected] http://mail.python.org/mailman/listinfo/sapug
