For instance, currently I receive an error like:
Code: Select all
testShouldReturnValidPkid -> Expected call count for [loadSomething] was [1] got [2]The required invocation of loadSomething absolutely must not exeed 3 calls in the context of so and so function, otherwise this or that system will be effected. This is due to the fact that sometimes, somethings go wrong, etc, etc...
You get the point I'm sure...basically just want to add more to a generic error message when expectations are not met.
2) Next question has to do with setting expectations and best practices...seems a powerful idea...holding an implementation to something of a contract, but I can see this getting tedious, messy and maybe difficult to maintain as implementation is much more dynamic than it's interface...
Using expectations frequently in your experience, has it led to a more structured, organzied approach to developing software, or does it cause more headaches than it's worth?