|
From: Colin K. <col...@us...> - 2004-06-24 06:50:31
|
Update of /cvsroot/nmock/website In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv5355 Modified Files: index.html Log Message: - Minor formatting of the code sample (indentation). Index: index.html =================================================================== RCS file: /cvsroot/nmock/website/index.html,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -d -r1.4 -r1.5 *** index.html 24 Jun 2004 06:36:38 -0000 1.4 --- index.html 24 Jun 2004 06:50:22 -0000 1.5 *************** *** 48,1280 **** </style> ! <p>NMock is a dynamic mock-object library for .NET. Its purpose is to provide a clean API for rapidly creating mock ! implementations of custom objects and verifying that objects interact with them correctly from unit tests.</p> ! <p>A mock:</p> ! <ul> ! <li>takes on the interface of another object, allowing it to be substituted for a real one for testing ! purposes.</li> [...2171 lines suppressed...] ! <p>The power of constraints is that you can flexibly specify your expectations <i>before</i> your code under test runs, allowing fail fast.</p> ! <p>You can easily create custom constraints by implementing the IConstraint interface, or passing a delegate into the Constraint class.</p> ! <h1>Tips</h1> ! <p><span style="font-weight: bold;">Syntactic sugar</span>: Because 90% of the time, the two constraints you use are IsEqual() and IsAnything(), these can be replaced with object and null arguments respectively. The above example can be shortened to mock.Expect("Eat", "cheese", null, null).</p> ! <p><span style="font-weight: bold;">Test layout</span>: Tests that use mocks are easier to read if they follow a standard layout. We break the test into four parts: "Setup" initializes any objects/mocks and puts them into the correct state before a test. "Expectations" specifies what you expect to happen - this is the actual 'test' bit. "Execute" runs the code under test - this is where you'd typically get a failure. "Verify" performs any post-execution checks including verifying all the mocks expectations have been met and any additional assertions.</p> ! <p><span style="font-weight: bold;">Externalize dependencies</span>: Inversion of Control (AKA Dependency Inversion Principle, Dependency Injector Pattern). Passing dependencies in from the outside decouples class under test from a particular implementation of the dependency (a good practice in general), making it easier to mock.</p> ! <p><span style="font-weight: bold;">Return values</span>: If the method being mocked returns a value or throws an exception, you can use ExpectAndReturn() or ExpectAndThrow() to specify what the mock should return. You can also use SetupResult() which does not associate an expectation and doesn't care how many times the method is called.</p> ! <p><span style="font-weight: bold;">Mocking classes</span>: NMock supports mocking of classes with virtual methods as well as interfaces. The merits of when to mock classes and interfaces is a religious debate. However, use of interfaces is highly recommended.</p> ! <p><span style="font-weight: bold;">Don't mock things you don't own</span>: It's awkward and painful trying to mock someone else's API (such as ADO.NET), leading to hard to read tests and assumptions about how the API works. On the other hand, mocking your own APIs leads you down the path of creating cleaner interfaces, which can never hurt. If dealing with external APIs, create your own clean abstraction suited for your purposes, which you can mock easily. For testing the abstraction itself, don't use mocks, use the real thing. This is the opposite of the usage commonly associated with using mocks, which usually leads to brittle and cumbersome tests.</p> ! ! <p><span style="font-weight: bold;">PropertyConstraint</span>: Allows you to setup constraints on properties of objects.</p> |