test-doubles.md
... ...
@@ -33,7 +33,7 @@ class TemperatureConverterTest < MiniTest::Test
33 33
end
34 34
```
35 35
36
-This is very easy. The SUT does not depend on other classes.
36
+This is very easy. The SUT does not depend on other classes; the state change can be verified directly.
37 37
38 38
### Testing messages received from others -- When to use a stub
39 39
... ...
@@ -46,12 +46,15 @@ It will look something like this:
46 46
Converter.new(FToCConverter).convert(32)
47 47
48 48
Now our Converter class depends on a collaborator, FToCConverter. XTD calls this an
49
-"indirect input" (p. 125), and the name it gives to this kind of collaborator is a DOC -- depended-on component. We could test Converter with a
50
-specific Collaborator (FToCConverter) or we can try to test the SUT in isolation.
49
+"indirect input" (p. 125), and the name it gives to this kind of collaborator is a DOC -- a "depended-on component."
50
+We could test Converter with a specific Collaborator (FToCConverter) or we can try to test the SUT in isolation.
51
+If we can test the SUT in isolation, then there will be fewer dependencies on other objects,
52
+which will make our test less brittle.
51 53
52 54
When we test the converter, we are not attempting to establish whether the conversion is correct;
53
-instead, we want to verify that it can delegate the 32 to the specific converter and return the
54
-value. Additionally, we may be writing the main converter first. We may not even know the range of
55
+instead, we want to verify that it can delegate the 32 to the specific converter and return a
56
+value. For the verification of the specific converter, we will write separate tests for that.
57
+Additionally, we may be writing the main converter first. We may not even know the range of
55 58
specific converters we are going to want, or have one in hand.
56 59
57 60
#### Stubbing
... ...
@@ -90,7 +93,7 @@ class ConverterTest < MiniTest::Test
90 93
end
91 94
```
92 95
93
-**NOTE:** In the real world, this is not how it's done. Why? Because in this test, _we don't care about
96
+**NOTE:** In the real world, this is not quite how it's done. Why? Because in this test, _we don't care about
94 97
FToCConverter_. All we care about is making available to the test an object that exposes a `convert`
95 98
method that returns a specific value, so that we van validate that the main `convert` method on
96 99
`Converter` leverages it. In short, we want to write the least amount of code to see that the plumbing