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.

[robin-june.livejournal.com]

So your school, like my grad school, had a problem keeping Computer Science teachers because it was so easy for them to make more money by escaping into the wild?

[poltr1]

Actually, no. My CS department faculty were big into research and the mathematical aspects -- discrete math, artificial intelligence, semantic networks, that sort of thing. I believe their primary focus was to prepare students for graduate school, not jobs and industry. If I recall the discussion, they were looking for someone outside the faculty to teach the software engineering class, and they couldn't find anyone local to the area willing to teach it.

[tigertoy.livejournal.com]

I dropped my software engineering class in my last semester as an undergrad because (a) after the first couple of weeks, it was clear the project was going to suck, and (b) I did not need the class specifically or the credit hours to graduate. But I don't think unit testing was a major topic, if covered at all. (I took the class because some of my co-workers had taken it in a previous semester, and got to do a project that was cool.)

I hope things are different in colleges today, but back in my day (University of Illinois, class of 1985), computer science instruction was pretty much confined to academic theory. Practical concerns (in other words, really learning how to be a programmer) only came from on the job learning. If you were good, you learned the theory and could apply it in the real world; if you weren't good, you got a job and helped to contribute to the industry's low expectations of programmers. I learned a fair bit about real-world programming while I was in college because I had a part-time job. I learned a bunch of useful things in class, but almost nothing about how to be a programmer.