On Thu, 3 Jan 2013, Japhy Bartlett wrote:
The general idea is to write tests that use your code in realistic ways and check the results. So if you have a function that takes an input and returns a result, you write a test that passes that function an input checks the result. If some inputs should make it error, you write a test that checks that it errors. In web programming, a common thing is to make a web request with different variations of GET / PUT params, then check that it returns the right status code, or that the result is valid JSON, etc. Basically, try to simulate all the things a real world user would be able to use, and test that your code does what you intend for it to do.TDD is a good principle but usually seems a little too pedantic for real world programming. Where tests (in my experience) get really useful is in making sure that a new change hasn't unexpectedly broken something already written.
That's funny, I find it exactly the opposite - unless I'm writing some prototype throw-away code, doing TDD has actually exposed problems with the underlying program structure precisely because it *is* pedantic.
Granted, if I needed to get a fix in place in production code that was costing buckets of cash every minute it wasn't fixed, I'd write the code, push that out, and *then* write the tests... but when I've been practicing TDD I've not had that problem.
My experience is that it has a tendency to bundle all the development costs right up front - instead of a little here, a little there.
But... that's just my experience ;) -Wayne
_______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
