Should I remove my mock/stub NSubstitute once my actual implementation has been developed?

[Nicodemus Chan]

NSubstitute can be used as a placeholder for an object that has yet been developed.

However, once my object has been implemented, how far should I go to replace the NSubstitute mock with the actual implemented object?

I foresee various answers from yes to no to depends.

Arguments for Yes, would make my tests function as integration tests, to make sure that the interface between objects was implemented correctly and that the understanding of the agreed upon behaviour of classes was correct.

Arguments for No would be that it could expose the implementation of a class to the calling functions. We should always program to an interface and if we need integration tests, then there should be separate Integration tests written for it. If there are errors, then the creation of the NSubstitute mock should be reviewed.

Opinions?

[David Tchepak]

This is a very interesting question! :) I think your existing arguments show you are considering many of the important points here. 

Perhaps another angle is why not avoid mocking altogether and just use real objects?

For developers that substitute for a logical interface (rather than for a specific object implementation that has not been developed yet) then I think they will prefer not to replace with an actual implementation, as there is not a single implementation to replace. (Another way to think about this is that the substitute is already an additional implementation of that interface. Mocking libraries are a short cut for manually writing this implementation.).

Test doubles are not just about placeholders for pending development though. They also let us do things like reliably test conditions that would be intermittent with real objects. For example, testing how a class reacts when the service it is calling is down, or overloaded, or returns an error code, etc. In these cases it is generally not feasible to replace with a production object.

If you have not seen it already you may want to look into Contract Tests as described here: https://martinfowler.com/bliki/ContractTest.html (the term is a bit overloaded I think, so be mindful of that while googling :) ). That seems a mix of both options: keeping test doubles, but ensuring they stay in sync with reality. 

Also possibly related to this question is the London vs. Chicago/Detroit schools of TDD, which emphasise interaction testing (generally lots of test doubles) and state based testing respectively. This, along with general top-down vs. bottom-up development styles, could also influence peoples answer to this question. (See [1], [2], [3])

Hope this helps :)

Regards,

David

[1]: https://softwareengineering.stackexchange.com/q/123627/58459

[2]: https://github.com/testdouble/contributing-tests/wiki/London-school-TDD

[3]: https://github.com/testdouble/contributing-tests/wiki/Detroit-school-TDD

--
You received this message because you are subscribed to the Google Groups "NSubstitute" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nsubstitute...@googlegroups.com.
To post to this group, send email to nsubs...@googlegroups.com.
Visit this group at https://groups.google.com/group/nsubstitute.
For more options, visit https://groups.google.com/d/optout.

[Nicodemus Chan]

Thanks. I think your answer helped to clarify my thoughts. I guess the answer is it depends on the reason for using NSubstitute in the first place.

If used as a temporary placeholder for other objects that have not been developed yet, then I think it would be alright to replace it.

But if used as a double to substitute for an inconsistent object or slow responding service then we should keep it.

Also, thanks for the links.

Nico.