The only thing I don’t really get with unit tests, is that you need to think what might go wrong before you can write a test for it.

I find the reason stuff breaks is that I didn’t think of how something could be broken in the first place, and if I had, I may not have spent the time to rite a unit test I just would have spent the time making sure it had the right checks in there in the first place.

A tricky one huh!

Unit testing is very different from functional testing in that most of the things you are testing are at a very granular level. It’s difficult to test higher level user interface issues.

But for example, you have a variable in your code that should be an integer. So you setup a test case to assert that that variable is an integer, and of course it passes. Now, two months down the line when you’re coding some other piece, you accidentally turn that into a string to accomplish something else but of course you don’t have the foggiest memory of why it needs to be an integer for some other piece of your code.

So you run your long list of unit tests you’ve accumulated and you get all green lights except for that one. So then you fix it.

Hope that makes a lil sense…I’m going to work on a full post on this topic for ya

Any insights, links, etc!?

I tried for years to ignore the facts about this one, but it’s absolutely true. I almost NEVER build in enough time for changes, bug fixing or such like and usually quote on the “perfect” project, but it’s just not practical to do that if you want some kind of a life outside of work!!!