daily-email: add 2023-07-16
When writing a failing test, youre designing your code
This commit is contained in:
parent
f15b60e5bc
commit
ae57acc8bc
1 changed files with 25 additions and 0 deletions
25
src/content/daily-email/2023-07-16.md
Normal file
25
src/content/daily-email/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: >
|
||||
archive/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