As far as I know from eXtreme Programming and unit testing, tests must be done by another developer before another one develop the tested method (or from the same developers but test must be written before the method implementation).
Ok, seems good, we just need to test if a method has a good behavior when I give it some parameters.
But the difference between theory and practice is that in theory there isn’t but in practice there is…
The first time I’ve tried to test, I’ve found it difficult in some cases due to relations between objects. I discovered mocking practice and I found it very useful but some concepts make me doubt.
First, mocking implicit says : “You know how the method runs because you must to know what other objects it needs…”. Well, in theory that’s my friend bob which writes the test and he just knows that the method must return true when I give it “john” string… It’s me who code this method using a dao to access a database instead of using an hashtable in memory…
How my poor friend Bob will write its test ? He will anticipate my work…
Ok, seems to not be the pure theory but no matter. But if I look at the documentation of a lot of mock frameworks, they allow me to test how many times a method is called and in what order ! ouch…
But if my friend Bob must test this method like that to ensure good use of dependencies, the method must be written before the test, isn’t it ?
Hum… Help my friend Bob…
When do we stop to use mock mechanism (order verification and so on) ?
When mock mechanisms are useful ?
Theory, practice and mock : what is the best balance ?
What you seem to be missing from your description is the concept of separating contract from implementation. In C# and Java, we have interfaces. In C++, a class composed only of pure virtual functions can fill this role. These aren’t really necessary, but helpful in establishing the logical separation. So instead of the confusion you seem to be experiencing, practice should go more like: Bob writes the unit tests for one particular class/unit of functionality. In doing so, he defines one or more interfaces (contracts) for other classes/units that will be needed to support this one. Instead of needing to write those right now, he fills them in with mock objects to provide for the indirect input and output required by his test and the system under test. Thus the output of a set of unit tests is not just the tests to drive development of a single unit, but that plus the contracts required to be implemented by other code to support the unit currently under development.