Anatomy

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

Scopes

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

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

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

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.

Scenarios

Behavior

Asserting

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

Comments

No comments yet.