Welcome

TestByWire is an extension to your Unit Test framework , which automatically injects dependencies, makes it easy to stub calls and makes stubbing of private non-injected dependencies possible.

Additionally, TestByWire introduces a new BDD like syntax that strictly enforces AAA unit testing. This will make sure you call only one method on your test target and only makes one assert in each test.

Using TestByWire has shown to actually make the production code adhere to the SOLID principles as a side effect to the strict way of testing.

Video Tutorials

Guides and Reference

Guides and reference is being added in the Documentation section.

Short Introduction

Now, what can TestByWire do for your code? Imagine you have the following class that you need to put under test:

class Payment
{
  private ILogger _log;
  private IDataLayer _dal;

  public Payment(ILogger log)
  {
    _log = log;
    _dal = new SqlServerDataLayer();
  }

  public void TransferFunds(string fromAccountId, string toAccountId, int amount)
  {
    _log.Trace(“Transfering funds from “ + fromAccountId + “ to “ + toAccountId);
    
    bool result = _dal.WithdrawCash(fromAccountId, amount);

    if(result)
      _dal.DepositCash(toAccountId, amount);
   }
}


To test this class, in your test class inherit from TestTarget<T> where T is the class under test – here Payment:

[TestClass]
public class PaymentTest : TestTarget<Payment>
{
  [TestMethod]
  public void TransferFundsTest()
  {
    When.Calling.TransferFunds(“10”, “20”, 200);

    Then<ILogger>.Should(l => l.Trace());
  }
}


What happens behind the scene is that TestByWire automatically will create stubs of any interface or class it encounters in the constructor.

As you might notice from the syntax in the sample code, executing the test itself is done in a Gherkin like syntax making the test very declarative and easy to read.

To execute a method on the class under test, simple spell out: When.Calling.MethodName. In the same manner, assertions are made using the Then<T> construct. If, as in the sample above, an assertion about a call to a dependency has to be made, place the dependency’s interface in the Then generic parameter and call Satisfies with the action to assert. Plain and simple.

In the Payment class, the _dal member field is instantiated in the constructor as a hardcoded dependency that is not immediately stubable. TestByWire can, however, do something about that. It is called Late Bound Stubbing. This means that yes, the constructor can initialize the field, but after the constructor has executed, TestByWire will override that field with a stub. Consider the test now:

[TestClass]
[UseStubLateBound(“_dal”)]
public class PaymentTest : TestTarget<Payment>
{
  [TestMethod]
  public void TransferFundsTest()
  {
    Given.That<IDataLayer>(d => d.WithdrawCash(null,0)).Returns(true);

    When.Calling.TransferFunds(“10”, “20”, 200);

    Then<ILogger>.Should(l => l.Trace());
  }
}


The attribute UseLateBoundStub will instruct the framework to replace the field with the name provided with a stub of the same type as the field. This also means that the system can be given behavior instructions via the Given statement also introduced in the test above.

The Given directive tells the system that the stub of type IDataLayer must return true if the method WithdrawCash is called. Arguments will be completely ignored because setting up a match on the behavior would in reality impose an extra assert that is undesired in TestByWire.

The final statement in the test is the Then<ILogger> clause. This is the actual assert. Calling Should with an action or function will determine if the actual method call was actually ever made by the code under test.

The examples shown here does not show all TestByWire's functionality. See more samples by downloading the source and look in the Tutorial folder.

Last edited Sep 12, 2011 at 8:18 PM by RasmusTherkelsen, version 21