31 lines
1.2 KiB
Markdown
31 lines
1.2 KiB
Markdown
|
---
|
||
|
|
title: >
|
||
|
|
Once you start writing tests, you can't stop
|
||
|
|
pubDate: 2023-07-01
|
||
|
|
permalink: >-
|
||
|
|
archive/2023/07/01/once-you-start-writing-tests-you-cant-stop
|
||
|
|
tags:
|
||
|
|
- automated-testing
|
||
|
|
- test-driven-development
|
||
|
|
---
|
||
|
|
|
||
|
|
Once you start testing/TDD, you can't go back
|
||
|
|
|
||
|
|
Once you start writing automated tests or doing test-driven development, you can't go back to not doing it.
|
||
|
|
|
||
|
|
When adding a new feature, you'd need to test every situation and use case manually in a browser or command line - and, very likely, do so multiple times.
|
||
|
|
|
||
|
|
When fixing a bug, you'd need to follow the exact steps to replicate it and see it before attempting a fix. Again, you'd also need to test it manually.
|
||
|
|
|
||
|
|
Also, because it passes a manual test, there's no guarantee it won't break unexpectedly in the future.
|
||
|
|
|
||
|
|
While refactoring code without tests, bugs and regressions could be introduced as there's no test suite to run and ensure they're still passing.
|
||
|
|
|
||
|
|
## Here's the thing
|
||
|
|
|
||
|
|
When you're used to writing tests and doing test-driven development, you get used to the quick feedback loops and the confidence to make changes.
|
||
|
|
|
||
|
|
It's easier to create a test that proves a bug exists and shows it'safixed because the test passes.
|
||
|
|
|
||
|
|
Once you have these things, you can't stop and go back to not having tests.
|