Agreed! The unit test needs to contain a bit more than just a check if the function exists :D

Unit testing is rather vague terminology. That could cover a broad range of possibilities. Sometimes, the "unit" is a pre-existing product and the developer is simply adding some new software functionality to the product. Other times, the "unit" and the software are being developed simultaneously and in conjunction with one another. The hardware unit and the software both need to be tested as parts of a complete system. When testing a complete system, there may not be any standard method or model that one can go by, and one may not be given very specific requirements or criteria. That's when testers have to use their own initiative and creativity and think up their own "what if" scenarios. Think of the Global Positioning System. It's comprised of a satellite network and it's software system, plus the ground receiving units and their software system all working in conjunction with one another. On top of that there is a satellite launching system that must put the satellites in very precise geosynchronous orbits. There is (was) no real model for testing such a system. People had to get creative. Obviously, one wants to make sure that the satellite network works in conjunction with the receiving units before spending tens of billions of dollars to put the satellites into orbit. So, maybe, the satellites are stationed on the ground and the receiving units are put up in planes. Only, one has to keep in mind that the satellites send out precise clock signals to the receivers, and the satellite clocks run slower on earth than they would in high orbit due to the effects of gravity. One would have to calculate the difference between the clock speed on earth and the clock speed in orbit and have the programmers modify either the satellite software or the receiver software to simulate satellites in space, when the satellites are actually earthbound. It turns out that coronal mass ejections from the sun can effect the cesium decay rates of the nuclear clocks used by the satellites. Should the system detect coronal mass ejections and correct for the change in clock speed? Has anyone even considered that? Sometimes there are things that one runs into in testing that the system designers have not anticipated. All one can do is inform them and let them decide what to do about it. When it comes to unit testing in conjunction with software applications, you pretty much have to take it on a case by case basis, and tailor your testing to fit the particular system under test.

Kepil: There are different level of coverage (statement coverage, branch coverage,... etc) and you may decide which level to go with. if the unit (class) is very complicated, then covering all possible scenarios might be impossible or infeasible. Jan: Functionality tests should prove if the function is correct or not. Jerry: In unit testing, a unit should not be more than one class. This class should be tested in isolation from other parts of the system (hardware/software).

One question I have - how often do you have that problem in that organisation? Does the development team as a whole need a bit of guidance on what to test, or was it just that individual? There should be ways of you (or your manager) discussing the need for better unit testing and organising something - either a team training or a 1-2-1 coaching session. In my experience, people want to do do their job well, so the challenge is to help the developers improve... without you becoming the tester they all dread!