<style> .reveal { font-family: Roboto, Source Sans Pro, Helvetica, sans-serif; font-size: 42px; font-weight: 300; } .reveal h1, .reveal h2, .reveal h3, .reveal h4, .reveal h5, .reveal h6 { margin: 0 0 20px 0; font-family: Roboto, Source Sans Pro, Helvetica, sans-serif; font-weight: 500; line-height: 1.2; letter-spacing: normal; text-transform: uppercase; text-shadow: none; word-wrap: break-word; } .reveal section img { margin: initial !important; background: initial !important; border: initial !important; box-shadow: initial !important; } </style> # From Software Testing to TDD --- ## Test Pyramid --- <img src="https://i.ibb.co/kJ8Wnmm/agile-testing-pyramid-onpath-testing-QA.png"> --- ## Unit Testing --- ### AAA / GWT Arrange-Act-Assert Given-When-Then *What is the structure of a unit test ?* --- #### A / G Arrange / Given Write code required to setup a test about to be run ```typescript= const userId: Id = Id('f4b5az654fzb65a4'); const roles: Role[] = []; const user: User = createUser(userId, roles); const adminRole: Role = Role.Admin; ``` --- #### A / W Act / When Invoke the functionality being tested ```typescript= const adminUser: User = setRole(user, adminRole); ``` --- #### A / T Assert / Then Check whether the expectations were met ```typescript= expect(adminUser.roles).toContain(adminRole); ``` --- #### All together ```typescript= const userId: Id = Id('f4b5az654fzb65a4'); const roles: Role[] = []; const user: User = createUser(userId, roles); const adminRole: Role = Role.Admin; const adminUser = setRole(user, adminRole); expect(adminUser.roles).toContain(adminRole); ``` --- ### FIRST *What are the characteristics of a unit test ?* --- #### F Fast Every test should run in a few milliseconds. Thousands of unit tests should run in a matter of seconds. A quick feedback loop helps developpers running unit tests while coding and get an instant feedback on what they are writing. --- #### I Independent / Isolated Tests should not depend on each other. Everything that the test needs to run should be set up in order to avoid side effects. Tests should guarantee that the result of the test is only based on a given initial state that can easily be updated. --- #### R Repeatable Every time a test is run alone or inside of a test suite it should ever have the same comportement, by being deterministic and without having conditional treatments. --- #### S Self-validating The only valuable information a test provide is if it pass or if it fails. No further check should be done to know the state of a test, such as manually checking information written in a file. --- #### T Thorough When executed together, tests for a functionality should cover all of its scenarios. Happy paths, when all behave as expected, but also edge and failure cases. --- ### Code coverage --- When a test is run, a certain amount of code is called. Code coverage indicates precicely what statements of the code base where called by the test while running. --- By summing the coverages of all the test you can hihlight portions of the code that have not been called by any test. --- ### TDD Test Driven Development --- TDD is **NOT** test after TDD is **NOT** test first --- <img height="500" src="https://i.imgflip.com/6x56t9.jpg"> --- Alternatives to TDD: - Browser + F5 - `console.log(result);` - `console.log('here');` - `console.log('please work');` - 🔴 --- #### Red, Green, Refactor <img width="600" src="https://i.ibb.co/bvM8L1C/TDD-red-green-refactor.png"> --- ### Baby steps Encourages to make short Red-Green-Refactor iterations. --- Long iterations result in a greater cognitive load to get the test pass, which ultimately leads to poor design and at best unnecessary code and at worst error introduction. --- Short iterations help to stay focuced and let the design emerge on its own step by step and it also help to get early validation of what you are doing. --- ### ZOMBIES *Where to start while writing a Test ?* --- <img width="600" src="https://i.ibb.co/7zbpgKY/zombies-2-D.png"> --- #### Z Zero Go after the simple problems first. *What happens when the array is empty ?* --- #### O One When all is set for the simplest case, go from zero: nothing happens to one: the simplest action is done. *What happens when the array contains one item which is not a special case ?* --- #### M Many Now that basics scenarios have been explored, it's time to treat more complex cases. *What happens when the array contains a special item that should not be processed ?* --- #### B Boundary Behaviors Default cases are easy to think of, but marginal behavior are often forgotten and could lead to unexpected behaviours in production. Boundaries Behaviors is here to reminds that tests should also cover theses cases. --- #### I Interface definition Your test helps to show how to use a given feature. You can also take it a step further and use your tests to try out different ways to call your code and discover one that best match the case you are working on. --- #### E Exercise Exceptional behavior As Boundary Behaviors is here to reminds that tests should cover cases that are not the firsts comming to mind, Exercise Exceptional behavior is here to reminds that tests should cover paths that lead to errors such as throw an exception when the input data is invalid. --- #### S Simple Scenarios, Simple Solutions Whatever your are testing, every test should highlight a simple solution to a simple and well identified scenario. Then your tests are simple to write, simple to understand and simple to update. --- ## References - [Unit Testing and the Arrange, Act and Assert (AAA) Pattern](https://medium.com/@pjbgf/title-testing-code-ocd-and-the-aaa-pattern-df453975ab80) - [F.I.R.S.T principles of testing](https://medium.com/@tasdikrahman/f-i-r-s-t-principles-of-testing-1a497acda8d6) - [TDD Guided by ZOMBIES](http://blog.wingman-sw.com/tdd-guided-by-zombies) - [Code Coverage](https://www.educba.com/code-coverage/) - [Baby Steps in TDD](https://medium.com/@heaton.cai/baby-steps-in-tdd-7761ad362e34)