Changes in c460be0: Updated test doubles (markdown)

				test-doubles.md
			
          @@ -1,4 +1,10 @@

          -Page references to xUnit Test Patterns

          +Page references to xUnit Test Patterns (XTD) and Practical Object-Oriented Design in Ruby (POODR)

          +

          +### The thing we are testing

          +

          +The thing we are testing is called a "System under test" (SUT) (XTD) or "object under test" (POODR, p. 195, Figure 9.1). We'll use SUT. It is fair to think about other things being under test, such as a class, object, method, or application, but the idea here is that the thing under test is defined by the scope of the test itself. Other objects may be involved, such as a "depended-on component" (DOC).

          +

          +

           * SUT - System under test

           * DOC - Depended-on component

          @@ -7,4 +13,8 @@ Page references to xUnit Test Patterns

           * "Stubbing" for Indirect Input - When the SUT makes calls to the DOC, it may take data from the DOC. This data would be an "indirect input." We want to simulate these indirect inputs. Why? Because the DOC may be unpredictable or unavailable. A thing that stands in for the DOC so as to provide indirect inputs to the SUT is called a stub. The stub receives the calls and returns pre-configured responses. We want to "install a Test Stub in place of the DOC" (129). Want to provide indirect inputs? We say that install the Test Stub to act as a "control point" (135). We call it a "control point" because we are trying to force the SUT down some path (524).

           * "Test Spies" or "Mocking" for Indirect Output - By "indirect output," we mean the calls the SUT makes to DOCs. Example: the SUT makes calls to a logger. We want to ensure that the DOC is getting called properly.

             * Procedural Behavior Verification. We want to capture the calls to the DOC during SUT execution and see what happens. This means installing a Test Spy. It receives the calls and records them; then afterwards we make assertions on what is recorded in the Spy. What to check indirect outputs? We say that that happens at an "observation point" (e.g., 137).

          -  * Expected Behavior. We install a Mock Object, and say in advance what we expect. If the Mock doesn't get what we expect, it fails the test.

          \ No newline at end of file

          +  * Expected Behavior. We install a Mock Object, and say in advance what we expect. If the Mock doesn't get what we expect, it fails the test.

          +

          +Other topics:

          +

          +* The four-phase test.

...	...	@@ -1,4 +1,10 @@
1		-Page references to xUnit Test Patterns
	1	+Page references to xUnit Test Patterns (XTD) and Practical Object-Oriented Design in Ruby (POODR)
	2	+
	3	+### The thing we are testing
	4	+
	5	+The thing we are testing is called a "System under test" (SUT) (XTD) or "object under test" (POODR, p. 195, Figure 9.1). We'll use SUT. It is fair to think about other things being under test, such as a class, object, method, or application, but the idea here is that the thing under test is defined by the scope of the test itself. Other objects may be involved, such as a "depended-on component" (DOC).
	6	+
	7	+
2	8
3	9	* SUT - System under test
4	10	* DOC - Depended-on component
...	...	@@ -7,4 +13,8 @@ Page references to xUnit Test Patterns
7	13	* "Stubbing" for Indirect Input - When the SUT makes calls to the DOC, it may take data from the DOC. This data would be an "indirect input." We want to simulate these indirect inputs. Why? Because the DOC may be unpredictable or unavailable. A thing that stands in for the DOC so as to provide indirect inputs to the SUT is called a stub. The stub receives the calls and returns pre-configured responses. We want to "install a Test Stub in place of the DOC" (129). Want to provide indirect inputs? We say that install the Test Stub to act as a "control point" (135). We call it a "control point" because we are trying to force the SUT down some path (524).
8	14	* "Test Spies" or "Mocking" for Indirect Output - By "indirect output," we mean the calls the SUT makes to DOCs. Example: the SUT makes calls to a logger. We want to ensure that the DOC is getting called properly.
9	15	* Procedural Behavior Verification. We want to capture the calls to the DOC during SUT execution and see what happens. This means installing a Test Spy. It receives the calls and records them; then afterwards we make assertions on what is recorded in the Spy. What to check indirect outputs? We say that that happens at an "observation point" (e.g., 137).
10		- * Expected Behavior. We install a Mock Object, and say in advance what we expect. If the Mock doesn't get what we expect, it fails the test.
...	...	\ No newline at end of file
	0	+ * Expected Behavior. We install a Mock Object, and say in advance what we expect. If the Mock doesn't get what we expect, it fails the test.
	1	+
	2	+Other topics:
	3	+
	4	+* The four-phase test.