Commits

Johannes Rudolph committed 51295f5

Comments (0)

Files changed (1)

-=== About SubSpec ===
+== About SubSpec ==
 
-SubSpec allows developers to write declarative tests operating at all layers of abstraction. SubSpec consists of a small set of primitive concepts that are highly composable. Based on the powerful xUnit testing framework, SubSpec is easy to integrate with existing testing environments.
+**SubSpec allows developers to write declarative tests operating at all layers of abstraction. SubSpec consists of a small set of primitive concepts that are highly composable. Based on the powerful xUnit testing framework, SubSpec is easy to integrate with existing testing environments.
+**
 
 SubSpec was originally started as a demo project by Phil Haack and Brad Wilson to show how a test framework supporting the BDD inspired Specification Style can be implemented on top of the powerful xUnit .Net testing framework.
 
 The original article anouncing the project can be found [[http://haacked.com/archive/2008/08/24/introducing-subspec.aspx|here]]. Since then, SubSpec has been officially part of the [[http://xunit.codeplex.com/|xUnit Samples]] project.
 
-=== Quickstart ===
+== Quickstart ==
 
 While SubSpec is inspired by the BDD methodology, its primary strength is to be used as a tool for writing **declarative **unit tests. A classical unit test (a Fact in xUnit) consists of three primitive operations:
 
 
 In order to support a **fluent syntax**, SubSpec allows you to specify each of the primitives as extension methods on strings that describe the primitive action that you pass as an argument to the Context (Arrange), Do (Act), or Assert (well, Assert) method.
 
-Because SubSpec allows you to **declare** the tests primitives instead of asking you to **execute** them, SubSpecs execution engine is free to **compose** them into test cases and take care of executing them. More specifically, SubSpec helps you enforce the "one assert per test" rule by generating **two** tests from the previous Specification:
+Because SubSpec allows you to **declare** the tests primitives instead of asking you to **execute** them, SubSpecs execution engine is free to **compose** them into test cases and take care of executing them. More specifically, SubSpec helps you enforce the "one assert per test" rule by generating **two** tests from the previous Specification, **one per verification (Assert or Observe, see below)**:
 
 # **Given **a new stack **with **an element pushed onto it, **expect **the stack is not empty.
 # **Given **a new stack **with **an element pushed onto it, **expect **the stacks Top is the pushed element.
 
-The following illustration depicts the way SubSpec **composes** the primitive actions of the above Specification into test cases **for each Assert**:
+The following illustration depicts the way SubSpec **composes** the primitive actions of the above Specification into test cases. **For each Assert a new Context is setup and the Do action applied:**
 
 {{http://jorudolph.files.wordpress.com/2010/08/subspec_assert1-e1283077403723.png|SubSpec Assert Flow}}
 
-Another verification primitive is available in SubSpec called Observe. Observe differs from Assert in that all Assertions share the same Context:
+Another verification primitive is available in SubSpec called **Observe**. Observe differs from Assert in that **all Observations share the same Context with the Do action applied:**
+
 {{http://jorudolph.files.wordpress.com/2010/08/subspec_observe1-e1283077433506.png|SubSpec Observe}}