Reply to thread

Message: <blockquote data-quote="mnmr" data-source="post: 1079222" data-attributes="member: 86308">I would recommend that you take a look at NSubstitute before settling on Moq. It has superior syntax (much more readable) and you can find many articles on Google from people explaining how to migrate from Moq to NSubstitute. One example <a href="http://www.tomdupont.net/2014/03/migrating-from-moq-to-nsubstitute.html" target="_blank">here</a> (shows a few examples side-by-side for the two frameworks)It should be noted that TypeMock uses the profiler API, which allows it to mock everything that happens - including intercepting object creation or access to non-virtual members or methods. This is not supported by any other mocking framework I know of. Thus, without TypeMock, your code needs to be "designed for unit testing". This means that classes must provide a means of injecting dependencies - typically in the form of a constructor where dependencies can be passed, but sometimes also by a writable property (I prefer to use constructor arguments for required dependencies and properties for optional ones). This is not the case with the current MP2 source code, so if you are serious about improving the unit test situation, I really think that one of the top priorities should be to refactor classes to be unit testable. Basically, every call to "new" (object creation) or "ServiceRegistration.Get" (object lookup) needs to be replaced with a constructor parameter (if the type is an MP2 type; it is often fine to create BCL types). Without this, no benefit comes from introducing a new unit test libraries, as no one will be able to use them to test the code.I've heard complaints that you cannot reliably cache instances retrieved from ServiceRegistration, as they might get replaced while the program is running. This sounds really weird and reeks of bad practice (in my humble, but vocal, opinion). Injecting dependencies via constructors would amount to the same as caching instances inside classes, so this practice would need to end if MP2 is to become unit testable. Should some service really require this ability, I suggest that we create a "service proxy" (basically a wrapper around the actual service, so that the instance itself can be replaced when the wrapper determines the need to do so) and pass the proxy as a dependency instead of the service itself. This would also have the benefit of making the behavior explicit (as in, "this dependency uses a proxy so it is not a true singleton") rather than the current "I don't know if anybody uses it, but technically it could happen" situation.These are my two cents, anyway <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile    :)" loading="lazy" data-shortname=":)" /></blockquote>

Verification