Tip 3: Test code isn't production code
Another common mistake is to treat test code just like production code. For instance, you'd like your code production code to be as dry as possible. But in test code, it's actually more important for tests to be readable and independent than to be dry. As a result, you'll want your tests to be more "moist" than dry. Specifically, you'll want to use literals a lot more in test code than you would in production.
In general, the most important properties of good tests are:
Independent - No test should affect the outcome of any other test. Put another way, you should be able to run your tests in any order and always have the same outcome. A corollary of this is that setup/teardown methods are evil (both because they increase dependence and they decrease readability)
Readable - The intent of each test should be immediately obvious (both by it's name and by its code).
Fast - Each test should run as quickly as possible, so the entire suite is also fast. The faster the suite, the more you'll run the tests, and the greater benefit you'll get (because you'll catch regressions quickly)
Precise - Each test should focus on testing one thing (and only one thing) well*. Ideally, if a test fails, you should know exactly what part of your production code broke by just glancing at the name of the test. Also, if your tests are precise, it's less likely that a change in your code will require you to change many different tests. In practice, precise tests are short and only have one assertion or expectation per test.
*Note: this doesn't apply to integration tests, which should make sure all components play nicely together.
subscribe to our feed