2024-02-01 21:46:17 +00:00
|
|
|
---
|
|
|
|
title: Automated tests mean you can make changes quicker
|
|
|
|
date: 2024-01-31
|
2024-05-20 22:58:27 +00:00
|
|
|
permalink: daily/2024/01/31/automated-tests-mean-you-can-make-changes-quicker
|
2024-02-01 21:46:17 +00:00
|
|
|
snippet: |
|
2024-09-08 22:09:54 +00:00
|
|
|
Automated tests mean you can make changes quicker and not worry about introducing regressions.
|
2024-02-01 21:46:17 +00:00
|
|
|
tags:
|
2024-09-08 22:09:54 +00:00
|
|
|
- software-development
|
|
|
|
- automated-testing
|
|
|
|
- test-driven-development
|
2024-02-01 21:46:17 +00:00
|
|
|
---
|
|
|
|
|
|
|
|
Before fixing [yesterday's bug][yesterday], because I'd written automated tests, I ran them to ensure they were all passing.
|
|
|
|
|
|
|
|
Then, I was able to focus solely on adding the new use case - starting with a failing test to replicate the issue and then getting it to pass.
|
|
|
|
|
|
|
|
Because it was already tested, I didn't need to worry about breaking any other functionality and introducing regressions.
|
|
|
|
|
|
|
|
When the new test was passing, I could run the whole test suite and ensure they still passed and things continued to work.
|
|
|
|
|
|
|
|
Without the tests, I'd either need to check everything else manually (which takes time) or worry that something could potentially be broken.
|
|
|
|
|
|
|
|
Having tests meant I could be confident that the new and existing functionality worked.
|
|
|
|
|
|
|
|
[yesterday]: {{site.url}}/archive/2024/01/30/tdd-doesnt-mean-you-know-everything-upfront
|