Lots of untested software out there.
Can make progress without process, keep info in head and just fire it out (bad thing.)
Other professions don't do this.
Professionals design first, then make stuff.
Results are better and faster (stronger, harder.)
Process is what matters, it adds structure to production and improves quality.
Some people don't bother with tests or only test afterword.
Lots of things are part of the process inclding conventions, standards, ect. TDD is part of the process.
Tests document code, catch future errors, save time. Tests just a tool.
- Decide what the code will do
- Write a test that will pass if the code does that thing
- Run the test, see it fail
- Write code
- Run the test, see it past
- Keep repeating process for everything
Very important to see the test fail first, bad tests don't fail at all and that's no use.
When back testing, write code, break the code, see it fail, fix the code.
- Design and plan before you code
- Document design
- Proof that code implements design
- Encourage desing of testable code
Building the plan gives better results! Testable Code == Good Code
Backtesting can reveal overly complicated code. Tests first prevent over complication because the tests themselves are simple.
- Modular
- Decoupled design
- Methods of limited scope
- Smaller methods
- Reduced cyclometic complexity (measure of how many paths there are through the code)
Red/Green: after writing code and gettin pass then refactor.
- Some things are too hard to test
- Some tests are too trivial to be useful
- Overtesting is possible, don't repeat tests
- Exploratory coding without tests is OK, back test and refactor if the exploratory code is going to be production code (spike and stabalize)