[Tutor] writing effective unittests

[Wayne Werner]

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