daily-email: add 2023-04-27
This commit is contained in:
		
							parent
							
								
									8ffafc444c
								
							
						
					
					
						commit
						37ac7cf277
					
				
					 1 changed files with 22 additions and 0 deletions
				
			
		
							
								
								
									
										22
									
								
								src/content/daily-email/2023-04-27.md
									
										
									
									
									
										Normal file
									
								
							
							
						
						
									
										22
									
								
								src/content/daily-email/2023-04-27.md
									
										
									
									
									
										Normal file
									
								
							|  | @ -0,0 +1,22 @@ | |||
| --- | ||||
| title: > | ||||
|   TDD: write the test backwards | ||||
| pubDate: 2023-04-27 | ||||
| permalink: > | ||||
|   archive/2023/04/27/tdd-write-the-test-backwards | ||||
| tags: | ||||
|   - automated-testing | ||||
|   - test-driven-development | ||||
| --- | ||||
| 
 | ||||
| When writing a test, something that I like to do is start by writing the first assertion first, and then work backwards. | ||||
| 
 | ||||
| My first assertion might be `self::assertTrue($result)`. | ||||
| 
 | ||||
| If I ran this test, it would fail because of the undefined `$result` variable - but it's clear to me what I need next by asking, "Where does `$result` come from?". | ||||
| 
 | ||||
| If I need to call a method on another class and get the result, I'll add it before the assertion. Then I repeat the process and ask, "What do I need for this to work?". | ||||
| 
 | ||||
| Maybe I need to create some users or content in the application for the class to query and return a result based on it, so I'll create those. | ||||
| 
 | ||||
| With this approach, I'm not making any assumptions about the test's prerequisites, and I usually find that I end up with cleaner and more focused tests. | ||||
		Loading…
	
	Add table
		Add a link
		
	
		Reference in a new issue