From 4120eb282f8f57370d17ab476816a375ccb53f61 Mon Sep 17 00:00:00 2001 From: Asiel Leal Celdeiro <15990580+lealceldeiro@users.noreply.github.com> Date: Wed, 6 Sep 2023 23:04:01 +0300 Subject: [PATCH] Add notes from "Clean Craftsmanship" --- CleanCraftsmanship/README.md | 32 ++++++++++++++++++++++++++------ 1 file changed, 26 insertions(+), 6 deletions(-) diff --git a/CleanCraftsmanship/README.md b/CleanCraftsmanship/README.md index 3279d8a..a30fa6a 100644 --- a/CleanCraftsmanship/README.md +++ b/CleanCraftsmanship/README.md @@ -36,21 +36,21 @@ the system behaves as specified. The essence of TDD entails the discipline to do the following: - Create a test suite that enables refactoring and is trusted to the extent that passage implies deployability. -That is, if the test suite passes, the system can be deployed. + That is, if the test suite passes, the system can be deployed. - Create production code that is decoupled enough to be testable and refactorable. - Create an extremely short-cycle feedback loop that maintains the task of writing programs with a stable rhythm and -productivity. + productivity. - Create tests and production code that are sufficiently decoupled from each other so as to allow convenient -maintenance of both, without the impediment of replicating changes between the two. + maintenance of both, without the impediment of replicating changes between the two. ### The Three Laws of TDD 1. The First Law: Write no production code until you have first written a test that fails due to the lack of that -production code. + production code. 2. The Second Law: Write no more of a test than is sufficient to fail or fail to compile. Resolve the failure by -writing some production code. + writing some production code. 3. The Third Law: Write no more production code than will resolve the currently failing test. Once the test passes, -write more test code. + write more test code. Benefits of applying these three laws: @@ -60,6 +60,26 @@ Benefits of applying these three laws: - You will produce a test suite that will give you the confidence to deploy. - You will create less-coupled designs. +### The fourth law + +Refactoring: First you write a small amount of failing test code. Then you write a small amount of passing production +code. Then you clean up the mess you just made. + +Rule 1: Write the test that forces you to write the code you already know you want to write. + +Rule 2: Make it fail. Make it pass. Clean it up. + +Rule 3: Don't go for the gold. + +> When you go for the gold too early, you tend to miss all the details around the outside. Also, you tend to miss +> the simplifying opportunities that those ancillary details provide. + +Rule 4: Write the simplest, most specific, the most *absurdly simple starting point* test that will fail. + +Rule 5: Generalize where possible. + +> As the tests get more specific, the code gets more generic. + ## Part I: Standards ## Part I: Ethics