34 lines
1.1 KiB
Markdown
34 lines
1.1 KiB
Markdown
|
---
|
||
|
title: >
|
||
|
Test to save your job
|
||
|
pubDate: 2023-09-24
|
||
|
permalink: >-
|
||
|
archive/2023/09/24/test-to-save-your-job
|
||
|
tags:
|
||
|
- software-development
|
||
|
- automated-testing
|
||
|
- test-driven-development
|
||
|
---
|
||
|
|
||
|
I've recently been going through my YouTube "Watch Later" list and watching (or rewatching) videos of conference and meetup talks that I saved to watch later.
|
||
|
|
||
|
Today's talk was by Matt Stauffer at one of the previous Laracon conferences.
|
||
|
|
||
|
I've quoted Matt previously when explaining what to test on applications. The answer: "The thing you'd lose your job for if it broke".
|
||
|
|
||
|
In this talk, Matt has a slide that goes further into this, titled "Test to save your job".
|
||
|
|
||
|
## What Matt said
|
||
|
|
||
|
The best place to start your tests is by asking yourself: "What part of this app, if broken, would make me worried for my job?"
|
||
|
|
||
|
* What's most likely to break?
|
||
|
* What do I have the least control over?
|
||
|
* What are we about to refactor?
|
||
|
* What would make my clients stress out?
|
||
|
* What would make me stressed out?
|
||
|
|
||
|
## What about you?
|
||
|
|
||
|
Do you have any other ways to decide what code to test? Reply and let me know, as I'd love to know.
|