Explain unit testing please

Question

I'm a little confused about unit testing. I see the value in things like automated testing. I think perhaps a good example would be the best way to help me understand. Lets say I have a binary search function I want unit tested.

Now in testing, I would want to know things like: Does the search find the first element, the last element, and other elements? Does the search correctly compare unicode characters. Does the search handle symbols and other "painful" characters. Would unit testing cover this, or am I missing it? How would you write unit tests for my binary search?

function search(collection, value){
 var start = 0, end = collection.length - 1, mid;
 while (start <= end) {
  mid = start + ((end - start) / 2);
  if (value == collection[mid])
   return mid;
  if (collection[mid] < value)
   end = mid - 1;
  else
       start = mid + 1;
 }
 return mid;
}

Psuedo code for unit tests would be lovely.

So, we might have:

function testFirst(){
 var collection = ['a','b','c','x','y','z'],first = 'a', findex = 0;
 assert(seach(collection,first),findex);
}
function testLast(){
 var collection = ['a','b','c','x','y','z'], last = 'z', lindex = 5;
 assert(seach(collection,last),lindex);
}

Answer 1

No, you're not missing it, this is what unit testing is designed to tell you. You have the right idea by testing good and bad input, edge cases, etc. You need one test for each condition. A test will set up any preconditions and then assert that your calculation (or whatever it may be) matches your expectations

Answer 2

You're correct in your expectations of unit testing; it's very much about validating and verifying the expected behaviour.

One value I think many folks miss about unit testing is that its value increases with time. When I write a piece of code, and write a unit test, I've basically just tested that the code does what I think it should, that it's not failing in any ways in which I have chosen to check, etc. These are good things, but they're of limited value, because they express the knowledge that you have of the system at the time; they can't help you with things you don't know about (is there a sneaky bug in my algorithm that I don't know about and didn't think to test for?).

The real value of Unit Tests, in my opinion, is the value they gain over time. This value takes two forms; documentation value and validation value.

The documentation value is the value of the unit test saying "this is what the author of the code expected this bit of code to do". It's hard to overstate the value of this sort of thing; when you've been on a project that has a large chunk of underdocumented legacy code, let me tell you, this sort of documentation value is like a miracle.

The other value is that of validation; as code lives on in projects, things get refactored, and changed, and shifted. Unit tests provide validation that the component that you thought worked in one way continues to work in that way. This can be invaluable in helping find errors that creep into projects. For example, changing a database solution can sometimes be see-through, but sometimes, those changes can cause unexpected shifts in the way some things work; unit testing the components which depend on your ORM can catch critical subtle shifts in the underlying behaviour. This really gets useful when you've got a chunk of code that's been working perfectly for years at a time, and nobody thinks to consider its potential role in a failure; those types of bugs can take a VERY long time to find, because the last place you're going to look is in the component that's been rock-solid for a very long time. Unit Testing provides validation of that "Rock Solidity".