This project is read-only.


This document outlines the ideas behind TestByWire and how a test is build up in TestByWire.


All dependency declarations can be visualized as scopes on different levels. There can be multiple declarations within a single scope but if there are multiple declarations about the same type within the same scope an exception will be thrown. Having the same declarations for the same type in two different scopes is fully supported - the scope closest to the execution will gain preference.

Global Scope
All declarations on class level are considered to be in the global scope. This scope information is cached for performance reasons between tests in the same fixture.

Local Scope
All declarations on method level are considered to be in local scope.

Dynamic Scope
The dynamic scope is filled imperatively by code in the test method.


Dependencies are automatically injected into the constructor if stubs can be created dynamically. Additionally TestByWire can break hardcoded dependencies by applying the UseStubLateBound attribute which will apply a stub to a private member field or property. To change or apply dependency behavior, attributes can be specified on class and method level.
  • Global Scope
    • UseStub
    • UseStubLateBound
  • Local Scope
    • UseStub
    • UseStubLateBound
    • ResetStub
  • Dynamic Scope


Stubs are declared using attributes. This means that it is only possible to specify a type and TestByWire will during executing control the life time of the type's instance.


Fakes can only be declared in the dynamic scope because the life time of fakes is controlled by the developer - not TestByWire. This is suitable for e.g. simulated data store in integration tests.




Last edited Jun 8, 2011 at 7:48 PM by RasmusTherkelsen, version 7


No comments yet.