HTML and CSS Reference
In-Depth Information
17.1.4 Reduce Duplication, Not Clarity
As with production code, we should actively remove duplication from tests to keep
them apt for change. If we decide to change the way we create objects of a given
type, it is preferable if that doesn't force us to change the creation of an object in
30 tests, unless all those tests specifically target the object creation.
However, there is a fine line to walk when reducing duplication in tests—if we
do it too aggressively, we may end up removing important communication from a
test. A good way to check if you have slimmed down a test too much is to extract it
from its test case along with the name of the test case; is it still clear what behavior
the test is describing? If it is not, e.g., because properties are not self-explanatory,
or the state of the system is not clear, then we have taken away too much.
Listing 17.7 shows a test from the chat client's message-list controller. The test
does not include code to create a controller instance, but still manages to clearly
state that setting the view with setView causes the element set as view to have its
class name set to “js-chat.”
Listing 17.7 Reading a test in isolation
TestCase("MessageListControllerSetViewTest", {
/* ... */
"test should set class to js-chat": function () {
assertClassName("js-chat", this.element);
Notice how this test also uses the assertClassName assertion, which can
be considered a high-level assertion.
To avoid repeating too much code throughout Part III, Real-World Test-Driven
Development in JavaScript, I may have sinned against this guideline a few times.
Listing 17.8 shows a test from the same test case that expects addMessage to
create new DOM elements and append them to the view.
Listing 17.8 Possibly too aggressively DRYed test
"test should add dd element with message": function () {
user: "Theodore",
message: "We are one"
Search WWH ::

Custom Search