Journey to TDD - Tracking Unscalable System
If you found this article and want to start at the beginning, this series starts here.
Smoke tests are good, yet unscalable - the system will grow larger than any one person can keep in their head.
This is especially true when creating new features and deploying the system. When the system is simple, expectations are simple.
When there is “differentiation” or “value-add”, expectations become different.
How to keep track of differences? How would the person deploying know what to expect as system complexity increases?
Ideas to keep track:
- a reference system
- a wiki page
- a README/DEPLOY/SMOKE_TEST file
- a comment in code
- CHECKLISTS!
Myriad of ways - these all become less sustainable as:
- timing - if there’s an error, what should happen?
- human tendencies - if someone forgot, what should happen?
- mismatch expectations - if the tracking system doesn’t match system’s reality, what should happen?
Ultimately, these add more processes around the system. An unscalable system begets unsustainable processes.
One must start solving the legacy system puzzle.