By now, almost all developers know how important Unit Testing is. And still everybody, including managers who create schedules, and developers who break them, follow an ignorant approach. From my experiences as a developer, I have been following the positive testing path. To elaborate on this, lets say i have written a function to multiply two numbers. While testing, 99% of the time, I was testing whether my function, given two numbers, was giving me the right answer or not. I was (and I admit i have seen people doing this like i was) ignoring that though

10* 2 =20, null *2 should throw a verbose, appropriate exception.
Now what i wrote about above, its just a tiny bit of ignorance, building up to what i call a positive testing path. How to change this parochial approach?
Lets see what i tried to do, am still doing, and trying to change the way i code.
Use XUnit. This is one major tool that need to embrace. (Infact when we hire these days, one of the qualities that we look for in a candidate si if he is comfortable using any xUnit tool.)
So now, when working on a piece of code, i actually work on two.
a. I write test cases (following TDD or not is not a concern for me) and
b. I write code.

My positive test for my code is to make it work.
My positive test for my test cases is to make them fail.

This way, I am able to see the shine on both the sides of the coin.
More to come on NUnit, automated builds and yes, I am working on a tool for automating/aiding this whole process while writing code.