Skip to main content
This lesson is in the beta phase, which means that it is ready for teaching by instructors outside of the original author team.
Testing
IntroductionWhat is testing? run tests?write tests?
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.
