Testing: Glossary

Testing improves confidence about your code. It doesn’t prove that code is correct.

Testing is a vehicle for both software design and software documentation.

Creating and executing tests should not be an afterthought. It should be an activity that goes hand-in-hand with code development.

Tests are themselves code. Thus, test code should follow the same overarching design principles as functional code (e.g. DRY, modular, reusable, commented, etc).

Legacy code is code without tests. It’s extremely challenging to change code that doesn’t have tests.

At the very least you should have an end-to-end test when starting to change code.

Try to add tests before making changes, work in small steps.

Having tests pass doesn’t mean your code is correct.

A test framework simplifies adding tests to your project.

Choose a framework that doesn’t get in your way and makes testing fun.

Coverage tools are useful to identify which parts of the code are executed with tests

TDD cycles between the phases red, green, and refactor

TDD cycles should be fast, run tests on every write

Writing tests first ensures you have tests and that they are working

Making code testable forces better style

It is much faster to work with code under test

Testing long methods is difficult since you can’t pinpoint a few lines of logic.

Testable code is also good code!

Changing code without tests can be dangerous. Work slowly and carefully making only the simplest changes first.

Write tests with an adversarial viewpoint.

Keep tests DRY, fixtures and parameter can help.

Changing a lot of test code for minor features can indicate your tests are not DRY and heavily coupled.

Testing a module’s interface focuses tests on what a user would typically observe. You don’t have to change as many tests when internal change.