-1

I inherited some code that uses Moq and is implemented in the code as:

private Mock<Shape> nativeShape;
private Mock<Document> nativeDoc;
// ...
nativeDoc = new Mock<Microsoft.Office.Interop.Word.Document>();
nativeShape = new Mock<Microsoft.Office.Interop.Word.Shape>();

The Git for Moq says how to use it, but not what it does and why I might want it. What is the purpose of this?

Nkosi
  • 191,971
  • 29
  • 311
  • 378
David Thielen
  • 22,779
  • 27
  • 83
  • 163
  • Possible duplicate of [What is Mocking?](https://stackoverflow.com/questions/2665812/what-is-mocking) – nvoigt Oct 17 '18 at 16:15
  • it is a mocking framework used to mock dependencies when testing https://github.com/moq/moq4#moq – Nkosi Oct 17 '18 at 16:15
  • 2
    Possible duplicate of [What is use of Moq?](https://stackoverflow.com/questions/678878/what-is-use-of-moq) – Nkosi Oct 17 '18 at 16:18
  • In what context is the shown code being used. I would like to assume it is used in a test but you would need to confirm that. – Nkosi Oct 17 '18 at 16:22

2 Answers2

0

Mock is used in test cases, especially if you're using Dependency Injection. If you are not familiar with Test Driven Development, I highly recommend reading up on it. (But that is a whole thread by itself.) It allows you to create objects that implement an interface or mimic an existing class. You can then define how the mocked-object behaves for a specific test case. A simple example is testing a business object that depends on another object, such as a Data Access Layer component. I recently created multiple tests for a business object and mocked the DAL. My test cases all depended on how the business object handled different results from the DAL (e.g. expected data set, an empty data set and an exception). This allowed me to test the business logic by itself, with no dependency on the DAL or the database. There are several libraries available that provide mocking functionality.

-1

Using your example, suppose you had an object - call it Foo - that required a Shape and Document in the constructor. In this case, you would have two options:

  1. Build an actual Document and an actual Shape, but using test data, and send these objects to the constructor during your test.
  2. Build a mock Document and a mock Shape with just the functionality you need to be able to run your test actually implemented and send these to your constructor for your test.

If your objects are large and complex, then the first option can become prohibitive for testing, especially for larger projects where you might not know the inner workings of how the objects are supposed to be constructed or if they require certain parameters (like private keys, thumbprints, etc.) that you might not have access to. This really becomes a concern when you start to use dependency injection. So, to get around this, you interface out the objects you need to pass around and then you build mock implementations that allow you to test with them. Of course, that gets pretty repetitive after awhile, which is why Moq exists.

Returning to the example, you could test Foo like so:

public void Foo_TestingFoo_DoesBar()
{
    var mockDoc = new Mock<Document>();
    var mockShape = new Mock<Shape>();

    // "implement" the methods you will need during your test
    mockDoc.Setup(...);
    mockShape.Setup(...);

    // Get the "actual" Document and Shape and use them as arguments to the ctor
    var foo = new Foo(mockDoc.Object, mockShape.Object);

    // Do stuff with foo
    foo.DoBar();

    // Verify that these objects were used how you expected them to be
    mockDoc.Verify(...);
    mockShape.Verify(...);
}
Woody1193
  • 3,389
  • 1
  • 16
  • 45