Move daily emails into the blog page
This commit is contained in:
parent
be69398931
commit
1b8441608f
828 changed files with 9 additions and 196 deletions
25
source/_posts/2023-07-16.md
Normal file
25
source/_posts/2023-07-16.md
Normal file
|
@ -0,0 +1,25 @@
|
|||
---
|
||||
title: >
|
||||
When writing a failing test, you're designing your code
|
||||
pubDate: 2023-07-16
|
||||
permalink: >-
|
||||
daily/2023/07/16/when-writing-a-failing-test-youre-designing-your-code
|
||||
tags:
|
||||
- automated-testing
|
||||
- test-driven-development
|
||||
---
|
||||
|
||||
When doing test-driven development, you start by writing a failing test and then write the code to make it pass.
|
||||
|
||||
This is the design phase where you ask questions and decide how you want the code to work.
|
||||
|
||||
* Are you going to use a global function or a method on a class?
|
||||
* Will you create a new class or add a method to an existing class?
|
||||
* What will it be called?
|
||||
* Will you use a named method or make the class invokable like a single-method Controller or Action?
|
||||
* Will it accept any parameters?
|
||||
* If so, what will the parameters be, what will they be named, and will they take any default values?
|
||||
* Will it return a value?
|
||||
* Should it throw an Exception?
|
||||
|
||||
You might iterate on the design and change it as you write more assertions or tests, but take the opportunity to decide how you want the code to work at this point before you start writing the implementation.
|
Loading…
Add table
Add a link
Reference in a new issue