test-doubles.md
... ...
@@ -33,18 +33,30 @@ class TemperatureConverterTest < MiniTest::Test
33 33
end
34 34
```
35 35
36
+This is very easy. The SUT does not depend on other classes.
37
+
36 38
### Testing messages received from others -- When to use a stub
37 39
38 40
Now let's say that we have a converter object that is capable of a variety of conversions. The
39 41
way this is going to work is that we are going to pass in the type of conversion we want, along
40
-with a value to be converted, and we want to get the right result. It will look something like this:
42
+with a value to be converted, and we want to get the right result.
43
+
44
+It will look something like this:
41 45
42 46
Converter.new(FToCConverter).convert(32)
43 47
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.
51
+
44 52
When we test the converter, we are not attempting to establish whether the conversion is correct;
45 53
instead, we want to verify that it can delegate the 32 to the specific converter and return the
46
-value. Additionally, we are writing the main converter first. We don't even know the range of
47
-specific converters we are going to want.
54
+value. Additionally, we may be writing the main converter first. We may not even know the range of
55
+specific converters we are going to want, or have one in hand.
56
+
57
+#### Stubbing
58
+
59
+A stub is an implementation that returns a canned answer (POODR, p. 210).
48 60
49 61
If we create a stub manually, we will want an instance of FToCConverter's convert method to return
50 62
a value that we can verify. It might look like this: