Lets get the priorities straight first...
In your role as a customer your main concern is not unit-testing
If you are using suppliers who produce software for you then you really shouldn't be concerned if they are using one methodology or another. Your stakes is to acquire some kind of a solution that will help achieve your goals. The only thing you should care about is wether or not that solution is acceptable. That's why we have acceptance testing as it lies in your responsibility to make sure that you get what you want. It is at the crucial moment of customer acceptance that money will be transacted from your company's pockets into the supplier's pocket.
You could demand unit-tests as deliverable requirement but there are several inherit problems with them, the most severe is that there is no sure-fire way beforehand to determine the metrics:
- What is the acceptable amount of unit tests?
Should there be 10 tests? How about 100 tests? How about 1000 tests? Actually, it is quite difficult to determine in the beginning how many tests you will need. The actual number is indeterminable really... like the halting problem... but we're not solving that problem.
You just want software that has unit-tests so you can continue development. Unit-tests don't tell what you've broken yet, but they're awesomely well suited to tell you when the code has a regression bug.
- What is an acceptable level of code coverage?
"100%, of course!" you'd think. Unfortunately that metric is misleading; even if you had 100% code coverage, are you really sure things are working as expected? It is possible to have 100% coverage but not be done.
What you really need to be doing is exploratory testing, i.e. find someone who is really good at breaking stuff and let them do the testing. To find the bugs that no developer has even thought of.
Also 100% is sometimes unattainable with pure unit tests if you have some necessary performance hacks and use design patterns that are difficult to test (search "singleton" and "tdd" in your favorite search engine and you'll find some examples).
You want the delivered software to work and the specification document is your only warranty that it will.
You will need higher level of testing
Your specification document has to be verified somehow. Each point has to be gone through with your suppliers having clear goals and acceptance criteria. A well functioning QA organization (or an awesome tester if you're on a budget and on a limited scope) would provide the test cases to check these acceptance criteria. You also need someone to verify those acceptance criteria.
There are several ways to verify your goals, and if someone tells me that you can't set any sane quality, performance and efficiency goals I will hit them in the head with big and heavy books on exploratory, performance and usability testing respectively. It may be easy to overkill with the goals, but knowledge and communication will help you set realistic goals.
I'm not a lawyer but most project contracts (which is basically the mother of all specifications for the project) I've read usually have a defect ratio criteria that stipulates on how many bugs that are deemed acceptable. The bugs are usually determined through severity, show-stopping bugs that are found by QA have a low tolerance while minor blemishes have a high tolerance. In real projects it is difficult to demand that software has to have 0 defects. Deadlines usually put a stop to that practice. It is at these situations that you have to start bargaining the scope.
Most supplied software I've seen usually aren't delivered with unit tests. You could argue the suppliers should be professional enough to deliver this, however the chief reason you want unit tests delivered to you is to make sure that you don't get regression bugs and also enable refactoring. In real life with projects on tight deadlines both the supplier and customer will be lowering the scope and unit-tests would usually go out the window and be removed from the list of required deliverables.
It is a bit sad that high profile open source software come delivered with unit-tests but a professional software developer can't, right?
So when do I, as a customer, get to care about unit testing?
I would argue that the only time you would truly care about unit testing is if the deliverable software is a self-sufficient component that isn't executed as a stand-alone program, for which the coarsest testing you can to do is a unit test. Class libraries would be one kind of product that can be delivered together with unit-tests.