├── .gitignore ├── CNAME ├── LICENSE ├── README.md ├── CONTRIBUTING.md ├── resources.md └── tdd.md /.gitignore: -------------------------------------------------------------------------------- 1 | /.idea/ 2 | -------------------------------------------------------------------------------- /CNAME: -------------------------------------------------------------------------------- 1 | kb.techexcellence.io -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Creative Commons Attribution 4.0 International Public License 2 | https://creativecommons.org/licenses/by/4.0/legalcode 3 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Knowledge Base 2 | 3 | [![pages-build-deployment](https://github.com/techexcellenceio/knowledge-base/actions/workflows/pages/pages-build-deployment/badge.svg)](https://github.com/techexcellenceio/knowledge-base/actions/workflows/pages/pages-build-deployment) 4 | 5 | Welcome to the Tech Excellence knowledge base. 6 | 7 | - [Resources](resources.md) 8 | - [Test Driven Development (TDD)](tdd.md) 9 | 10 | ## Licence 11 | 12 | CC BY 4.0 International 13 | 14 | Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License. 15 | 16 | ## Contributors 17 | 18 | The source for the knowledge base is on [GitHub](https://github.com/techexcellenceio/knowledge-base). 19 | 20 | - [Valentina Cupać](https://www.linkedin.com/in/valentinacupac/) ([valentinacupac](https://github.com/valentinacupac)) 21 | - [Joffrey Bonifay](https://www.linkedin.com/in/joffrey-bonifay/) ([joffreybonifay](https://github.com/JBonifay)) 22 | - [Dionisio Cortés Fernández](https://www.linkedin.com/in/dionisio-cortes-fernandez) ([dionisioC](https://github.com/dionisioC)) 23 | 24 | Our KB is currently in very early development stage. We welcome contributions and new contributors. Any pages you see on the KB are open to continuous revision. We are aware there are multiple interpretations and approaches, so perhaps you want to add your perspective or make corrections. To contribute, pease see instructions [contributing](CONTRIBUTING.md). You can also join our [Discord discussions](https://discord.gg/9b4dWYdHqS). 25 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | 1. Fork this repository https://github.com/techexcellenceio/knowledge-base. 4 | 2. Edit some pages. Please following the Referencing guidelines below. 5 | 3. Add your name, LinkedIn link & GitHub link on https://github.com/techexcellenceio/knowledge-base/blob/main/README.md (if your name is already listed, skip this). 6 | 7 | ## Referencing Guidelines 8 | 9 | ## Quoting Text 10 | 11 | If you copy-paste any sentence or part of sentence from the internet / book or a sentence said in audio, then you need to attribute it to the author. For example, "Tests should be coupled to the behavior of code and decoupled from the structure of code." (Kent Beck), even better add the source - i.e. the book, Twitter link, blog link, e.g. "Tests should be coupled to the behavior of code and decoupled from the structure of code." (Kent Beck, [Twitter](https://twitter.com/kentbeck/status/1182714083230904320)). Another example is "Integration tests cover controllers, while unit tests cover the domain model and algorithms." (Vladimir Khorkikov, [Unit Testing](https://www.amazon.com/Unit-Testing-Principles-Practices-Patterns-ebook/dp/B09782L692)). 12 | 13 | This is important for the following reasons: 14 | 15 | - Firstly, we avoid copyright infringement. Anything that was published by anyone in written/audio/video format (e.g. book, video, blog, LinkedIn, Twitter, YouTube) belongs to that author. We have to reference anything that was copy-pasted. 16 | - Secondly, we also provide readers with credible source - i.e. we didn't invent something, but go and see author XYZ who came up with the concept 17 | 18 | ## Referencing Ideas 19 | 20 | From a legal perspective, ideas themselves are NOT copyrighted, only the expression of ideas is copyrighted - this is referred to as the idea/expression dichotomy. So for example, the idea of TDD is NOT copyrighted (similarly other ideas arebn't copyrighted either), but a particular expression of the idea (e.g. copy-pasting a sentence from some TDD book, some Unit Testing book, etc.) IS copyrighted. 21 | 22 | For that reason: 23 | - For any IDEAS, you are not legally obligated to reference the source because ideas aren't owned. So for example, when I write about the TDD Red-Green-Refactor cycle and describe in my own words that cycle, then that's fine. It is however, _useful_ for me to reference the source of who invented the idea where possible, even though I am not legally obligated to do so. 24 | - For EXPRESSION of ideas, you are legally obligated to reference the source because the expression IS under copyright of the original author. See section "Quoting Text" 25 | 26 | -------------------------------------------------------------------------------- /resources.md: -------------------------------------------------------------------------------- 1 | # Resources 2 | 3 | If you want to add anything or make corrections, please see instructions [contributing](CONTRIBUTING.md). 4 | 5 | ## Books 6 | 7 | English: 8 | - [Test Driven Development: By Example (Kent Beck)](https://www.amazon.com/Test-Driven-Development-Kent-Beck-ebook/dp/B095SQ9WP4) 9 | - [Modern C++ Programming with Test-Driven Development: Code Better, Sleep Better (Jeff Langr)](https://www.amazon.com/Modern-Programming-Test-Driven-Development-Better-ebook/dp/B00HUEG8M8) 10 | - [Growing-Object-Oriented-Software-Guided-Tests](https://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627) 11 | - [ATDD-Example-Test-Driven-Development](https://www.amazon.com/ATDD-Example-Test-Driven-Development-Addison-Wesley/dp/0321784154) 12 | - [Extreme Programming Explained (Kent Beck, Cynthia Andres)](https://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658) 13 | - [xUnit Test Patterns: Refactoring Test Code (Gerard Meszaros)](https://www.amazon.fr/dp/0131495054?psc=1&ref=ppx_yo2ov_dt_b_product_details) 14 | - [Unit Testing Principles, Practices, and Patterns (Vladimir Khorikov)](https://www.amazon.com/Unit-Testing-Principles-Practices-Patterns/dp/1617296279) 15 | - [Continuous Delivery (Jez Humble, Dave Farley)](https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley-ebook/dp/B003YMNVC0) 16 | - [Software Engineering at Google (Titus Winters, Tom Manshreck, Hyrum K. Wright)](https://www.amazon.com/Software-Engineering-Google-Lessons-Programming/dp/1492082791) 17 | - [Clean Architecture (Robert C. Martin)](https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure-ebook/dp/B075LRM681) 18 | - [Domain Driven Design (Eric Evans)](https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software-ebook/dp/B00794TAUG) 19 | - [Implementing Domain-Driven Design (Vaughn Vernon)](https://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon-ebook/dp/B00BCLEBN8) 20 | - [Microservices Patterns (Chris Richardson)](https://www.amazon.com/Microservices-Patterns-examples-Chris-Richardson-ebook/dp/B09782192F) 21 | - [The Software Craftsman: Professionalism, Pragmatism, Pride (Sandro Mancuso)](https://www.amazon.com/Software-Craftsman-Professionalism-Pragmatism-Robert/dp/0134052501) 22 | - [Elegant Objects (Yegor Bugayenko) Vol.1](https://www.amazon.fr/dp/1519166915?psc=1&ref=ppx_yo2ov_dt_b_product_details) - [Vol2](https://www.amazon.com/Elegant-Objects-2-Yegor-Bugayenko/dp/1534908307) 23 | 24 | French: 25 | 26 | - [Software craft: TDD, Clean Code et autres pratiques essentielles](https://www.amazon.fr/Software-craft-autres-pratiques-essentielles/dp/2100825208) 27 | 28 | ## Websites / Blogs 29 | 30 | English: 31 | - [The Clean Code Blog (Uncle Bob)](https://blog.cleancoder.com/) 32 | - [Hexagonal Me (Juan Manuel Garrido de Paz)](https://jmgarridopaz.github.io/) 33 | 34 | French: 35 | 36 | ## Courses 37 | 38 | English: 39 | - [Robert "Uncle Bob" Martin Clean Code: Advanced TDD](https://cleancoders.com/library/all) 40 | 41 | French: 42 | - [Artisan developpeur (Benoit Gantaume)](https://compagnon.artisandeveloppeur.fr/courses) 43 | - [Wealcome](https://wealcomecompany.com/formations) 44 | 45 | ## Meetups 46 | 47 | English: 48 | - [Tech Excellence](https://www.meetup.com/techexcellence/) 49 | 50 | English / French: 51 | - [Software Craft Luxembourg](https://www.meetup.com/software-craft-luxembourg/) 52 | 53 | ## YouTube Channels 54 | 55 | English: 56 | - [Tech Excellence](https://www.youtube.com/@TechExcellence) 57 | - [Continuous Delivery](https://www.youtube.com/@ContinuousDelivery) 58 | - [JitterTed](https://www.youtube.com/@JitterTed) 59 | 60 | English / French: 61 | - [Software Craftsmanship Luxembourg](https://www.youtube.com/@softwarecraftsmanshipluxem8137) 62 | 63 | 64 | ## Videos 65 | 66 | English: 67 | 68 | - [TDD, Where Did It All Go Wrong (Ian Cooper)](https://www.youtube.com/watch?v=EZ05e7EMOLM) 69 | - [The Past (1968) and Future of Domain (driven) Design (Prof. David West)](https://www.youtube.com/watch?v=XH_awPS6hK4) 70 | 71 | French: 72 | 73 | 74 | ## Presentations: 75 | 76 | English: 77 | 78 | French: 79 | 80 | Portugese: 81 | - [Hexagonal Rails (Luiz Costa)](https://speakerdeck.com/gutomcosta/hexagonal-rails) 82 | 83 | 84 | -------------------------------------------------------------------------------- /tdd.md: -------------------------------------------------------------------------------- 1 | Disclaimer: Please note that this page is under intensive "draft" mode, so it is being actively updated. 2 | 3 | If you want to add anything or make corrections, please see instructions [contributing](CONTRIBUTING.md). 4 | 5 | You can also join our [Discord discussions](https://discord.gg/9b4dWYdHqS). 6 | 7 | # History 8 | 9 | TODO: Add the history of TDD, and the key people involved in development 10 | 11 | # Different types of test 12 | 13 | ## Unit tests 14 | 15 | - Unit tests help to refactor, 16 | - Unit tests remove *fear of change* 17 | - Unit tests protect us to break something 18 | 19 | TODO: Add Fowler's article where he remarks that there were so many different definitions of unit test evne when XP 20 | began, and the classification sociable vs solitary unit test. Explain difference interaction-based vs state-based vs 21 | output-based verifification. 22 | 23 | ## Integration tests 24 | 25 | TODO: Definition of integration test - different variants. For example, with sociable unit test, tests spanning multiple 26 | classes are NOT integration tests per se, they are still unit tests.... But with solitary unit test, tests spanning 27 | multiple classes are integration tests... Do intgeration tests include or not include business logic? (the two 28 | interpretations) 29 | 30 | ## Acceptance tests 31 | 32 | TODO: Interpretation of acceptance tests from e2e perspective (that's what many people see this as) - testing from the 33 | end user.... vs unit tests being acceptance tests (quoting Ian Cooper's video TDD Revisited) 34 | 35 | ## End-to-end tests 36 | 37 | TODO: Problems of definition of e2e tests, spanning vs not spanning third-party systems 38 | 39 | # Test driven development 40 | 41 | ## TDD rules 42 | 43 | * [Robert Martin's three rules](http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd) 44 | 45 | ```text 46 | - You are not allowed to write any production code unless it is to make a failing unit test pass. 47 | - You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. 48 | - You are not allowed to write any more production code than is sufficient to pass the one failing unit test. 49 | ``` 50 | 51 | * [Kent Beck's two rules]() 52 | 53 | [//]: # (find kent beck article/resource link about his rules) 54 | 55 | ```text 56 | - Don’t write a line of new code unless you first have a failing automated test 57 | - Eliminate duplication 58 | ``` 59 | 60 | * [Martin Fowler's three rules](https://martinfowler.com/bliki/TestDrivenDevelopment.html) 61 | 62 | ```text 63 | - Write a test for the next bit of functionality you want to add. 64 | - Write the functional code until the test passes. 65 | - Refactor both new and old code to make it well structured. 66 | ``` 67 | 68 | ## TDD cycle 69 | 70 | ### Red - Failing test 71 | 72 | Write a failing test, well [named](#tests-name), that test a behavior, **not a method**. 73 | 74 | We should test behaviors not classes ! 75 | 76 | TODO: Here wording needs to be clarified. Our unit tests are calling classes/methods inside the test itself, but the 77 | emphasis is on behavior... Also the difference of interpretatation of behavior as outcomes (testing behavior through 78 | state), versus interpretation of behavior as interactions. 79 | 80 | ### Green - Make it pass ! Fast ! 81 | 82 | Make it pass with the minimum required code, this step should be fast, it *must* take less than 1 minute, 83 | 84 | if not, it means your step is too big ! [see baby steps for more](#baby-steps) 85 | 86 | ### Blue - Refactor ! 87 | 88 | This is a step that is crucial and most of the time skipped by developers. 89 | 90 | In this step, you'll can remove duplicate, introduce some designs patterns, improve code readability. 91 | 92 | > **Never** forget to run tests after !!! 93 | > This will validate your modifications ! 94 | 95 | TODO: We also need to point out difference between localized vs more global refactoring... and avoiding premature design 96 | patterns. 97 | 98 | ## How to choose tests 99 | 100 | Tests must be chosen well in order to accomplish the next minimum line of code you want to add. 101 | 102 | Like a chess player, each step you take must be calculated 103 | and planned in order to complete the whole algorithm step by step. 104 | 105 | This means, you don't write a random unit test that won't help you complete the algorithm, 106 | but a precise test, which targets a precise addition. 107 | 108 | ## How much tests is enough 109 | 110 | As many tests as necessary to validate business behavior. 111 | 112 | This means that a method for operating a pacemaker will contain many more tests than a method for dropping candy from a 113 | candy machine. 114 | 115 | ## One assertion per test 116 | 117 | > The single assert rule means, 118 | > you should have a single logical assertion. 119 | > However, you can have multiple assert statements 120 | > that can be composed. 121 | > -- Uncle bob 122 | 123 | The Single Assert Rule maintains that a single logical assertion should follow a single logical action. 124 | 125 | ## Tests name 126 | 127 | "We should name our test functions for the action and assertion." (Uncle bob) 128 | 129 | ```java 130 | public void addMoneyUpdateCustomerBalance(){ // -- } 131 | public void computeXAndYReturnZZ(){ // -- } 132 | public void startSystemShouldEnableFeaturesXY(){ // -- } 133 | ``` 134 | 135 | TODO: Need to list the different variants of naming, for example another convention is with `should` 136 | 137 | ## Tests structure patterns 138 | 139 | ### AAA 140 | 141 | * Arrange 142 | * Act 143 | * Assert 144 | 145 | ### GWT 146 | 147 | * Given 148 | * When 149 | * Then 150 | 151 | ## Better assertions / Custom assertions 152 | 153 | Custom assertions are pretty easy to create, no need for external dependency: 154 | 155 | Example: 156 | 157 | ```java 158 | class Test { 159 | 160 | @Test 161 | public void shouldInvertName() { 162 | assertEquals("First", invert("First")); 163 | assertEquals("Last, First", invert("First Last")); 164 | assertEquals("Last, First", invert(" First Last ")); 165 | } 166 | 167 | public String invert(String fullname) { 168 | // -- 169 | } 170 | } 171 | ``` 172 | 173 | This can be replaced by 174 | 175 | ```java 176 | class Test { 177 | 178 | private void assertInverted(final String input, final String expected) { 179 | assertEquals(expected, invert(input)); 180 | } 181 | 182 | @Test 183 | public void shouldInvertName() { 184 | assertInverted("First", "First"); 185 | assertInverted("First Last", "Last, First"); 186 | assertInverted(" First Last ", "Last, First"); 187 | } 188 | 189 | public String invert(String fullname) { 190 | // -- 191 | } 192 | } 193 | ``` 194 | 195 | TODO: Describing setup helpers and assertion helpers 196 | 197 | ## Test FIRST 198 | 199 | * F for *Fast*: 200 | * This allows you to get **quick feedback.** 201 | * If your tests are slow, you are less likely to run them often. 202 | * I for *Isolated*: 203 | * A test must not depend on another one. 204 | * You can run test in aleatory order and this will always pass. 205 | * R for *Repeatable*: 206 | * A test can be repeated indefinitely. 207 | * If a unit test is network, database, or file dependent, it is more likely to fails. 208 | * S for *Self-validating*: 209 | * Test should contain one assertion validating the result of the function tested. 210 | * See [One assertion per test](#one-assertion-per-test) 211 | * T for *Thorough or Timely*: 212 | * Thoroughness 213 | * When we test a function, we need to test for happy and unhappy paths. 214 | * Timely 215 | * Unit tests should be written just before the production code that makes the test pass. 216 | 217 | ## Tests are SOLID 218 | 219 | TODO: Let's review this section, what's the source of this? 220 | 221 | Test should be SOLID as well as production code, a great explanation can be viewed in this Uncle Bob episode: 222 | 223 | [Test Design - Clean Code: Advanced TDD, Episode 21](https://cleancoders.com/episode/clean-code-episode-21) 224 | 225 | * S for *Single responsibility principle*: 226 | * Each test function, and each test class, should have one, and only one responsibility. which is the responsibility 227 | of the class it is testing. 228 | * O for *Open/Closed principle*: 229 | * The rule for tests is that, the production code should be open for extension, but the tests should be closed for 230 | modification. 231 | * We should be able to change the production code without changing the tests. 232 | * L for *Liskov substitution principle*: 233 | * Since we use polymorphism in our tests, we comply with the Liskov substitution principle. 234 | * I for *Interface segregation principle*: 235 | * If tests use an interface that contains methods that the tests don’t call, then the tests have too much knowledge. 236 | * D for *Dependency inversion principle*: 237 | * Tests are low level detail, they are clients of the production code. 238 | * Test code should depend on production code. 239 | * Production code should not depend on test code. 240 | 241 | ## Fragile tests 242 | 243 | ## Agnostic tests 244 | 245 | ## Test-code importance 246 | 247 | "Test code may be more important than production code since you can recreate the production code from the tests, but you 248 | can't recreate the tests from the production code." (Uncle 249 | bob, [Article](http://butunclebob.com/ArticleS.UncleBob.BastardChild)) 250 | 251 | ## Assert first 252 | 253 | ## Baby steps 254 | 255 | ## Mocking 256 | 257 | ## Transformation priority premise 258 | 259 | Great explanation in [Uncle bob article](https://blog.cleancoder.com/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html) 260 | 261 | * ({}–>nil) no code at all->code that employs nil 262 | * (nil->constant) 263 | * (constant->constant+) a simple constant to a more complex constant 264 | * (constant->scalar) replacing a constant with a variable or an argument 265 | * (statement->statements) adding more unconditional statements. 266 | * (unconditional->if) splitting the execution path 267 | * (scalar->array) 268 | * (array->container) 269 | * (statement->recursion) 270 | * (if->while) 271 | * (expression->function) replacing an expression with a function or algorithm 272 | * (variable->assignment) replacing the value of a variable. 273 | 274 | ## Getting stuck 275 | 276 | "Why do you get stuck? Because you were not adding sufficient generality to the production code. You were making the 277 | tests too specific, too quickly. The solution is to backtrack and then add specificity to the tests more slowly, while 278 | adding generality to the production code more quickly. This frequently forces you to choose a different set of tests to 279 | follow." (Uncle Bob) 280 | --------------------------------------------------------------------------------