Unit testing.....

[poltr1]

In the past couple of weeks, I've been tasked with writing unit tests for the code I developed. My project lead is big on unit testing, and wants the code to be tested thoroughly with many varied test cases.

What is unit testing? Wikipedia defines it thusly: "unit testing is a method by which individual units of source code are tested to determine if they are fit for use." What it means for my client is to identify test cases, determine what the anticipated results are, run the code, and check the results to see if they match the anticipated results.

This was something I never learned in college, This would have been covered in a software engineering class. There was one on the books, but we didn't have an instructor to teach that course. (Yeah, I can go on ab out the politics of my CS department, but I'll save that for another time.)

So I'm struggling with this. I can look at the data, and I can't tell if it looks right or not. I've asked for help, but the attitude I seem to get from both my project lead and tech lead is "We expect you to know these things." And so I write the tests, not know if if what I'm looking for is the right answer or not.

Comments

[billroper]

A large chunk of unit testing is making sure that your code is invulnerable to bad data. So if you pass in invalid data, the code should detect it and pass back an "invalid" flagged result. Negative tests are actually easier to write than positive tests; you just need to walk the code from top to bottom and look for things that will destroy you. NULL pointers as input are always good. (Or is that bad? :) )

The positive tests are more difficult, but if you can build a spreadsheet that replicates a simple calculation, you can demonstrate that you get the same answer as the Excel emulation.