HTML and CSS Reference
In-Depth Information
Ensuring that code is testable means ensuring it is loosely coupled and well
factored, thus flexible and easy to use, both as a whole and in parts. Writing tests
upfront as we do in test-driven development builds testability into the code.
17.3.3 Heckle and Break Code
Sometimes a test suite will be all green, yet the production code clearly exhibits
defects. The source to these kinds of errors are often found in the integration
between moving parts of the application, but sometimes they can be the result of
edge cases not catered for, or worse, bugs in tests.
A great way to smoke out errors in tests and generally assess the quality of a test
suite, is to intentionally introduce errors in production code and then make sure
the tests fail, and for the right reasons. The following “attacks” can prove useful to
find deficiencies in tests.
•
Flip the value of boolean expressions.
•
Remove return values.
•
Misspell or null variables and function arguments.
•
Introduce off-by-one errors in loops.
•
Mutate the value of internal variables.
For each intentional deficiency you introduce, run the tests. If they all pass, you
know that you have either stumbled upon untested code or code that simply doesn't
do anything. Either capture the bug with a new unit test or remove the offending
code, and continue.
17.3.4 Use JsLint
JsLint
1
is a “JavaScript Code Quality Tool.” Inspired by lint for C, it detects syntac-
tical errors, bad practices, and generally provides many more warnings than most
JavaScript runtimes do today. Syntax errors can cause weird problems in test cases.
A misplaced semicolon or comma can cause only some of your tests to run. Mak-
ing matters worse, the test runner may not be able to warn you about some tests
not being run. Using JsLint both on production code and tests alike will help you
remove typos and other syntax errors, making sure the tests run as expected.
