2024 DAPUG Conference Arnaud Bouchez Test Driven Design
1 like97 views
Testing is everything. We will share our own practical experience with testing, and see how may be come one step further, without losing too much productivity.
2024 DAPUG Conference Arnaud Bouchez Test Driven Design
- 1. Session 6 Test Driven Design DAPUG Hotel Hesselet, Nyborg Arnaud Bouchez - https://synopse.info
- 2. Sessions mORMot as a ToolBox From Classes/Components to Interface From RAD to REST/SOA Technical Debt Test Driven Design ORM mORmot Gems FPC and Lazarus
- 3. Test Driven Design Iterate Test First Unit Tests Integration Tests Performance Tests mORMot
- 4. Iterate
- 5. Iterate
- 6. Iterate
- 7. Iterate Coding is an ITERATIVE process Even up to the management level (projects) Ensure each step wont break any previous step Testing should be part of this process
- 8. Iterate Coding is an ITERATIVE process Most of the time: feature-oriented iterations (because this is what the client pays for) Sometimes: quality / refactoring iteration (but most likely done with an associated feature) Testing should be part of this process
- 9. Iterate Refactoring to isolate seams via interfaces 1. Know your subject 2. Identify responsibilities big picture 3. Study data structures 4. Break out big classes 5. Break out huge functions iterative process 6. Encapsulate global references 7. Testing is everything
- 10. Test First
- 11. Test First Test Driven Design means iterate from a test and into tests
- 12. Test First Test Driven Design means iterate from a test and into tests a.k.a. the it is not coffee, it is TDD time
- 13. Test First Test Driven Design means produces passing test 1. Write the test 2. Fails the test 3. Implements the feature 4. Fails the test ? Drink a coffee and go to 3. 5. Pass the test and all previous tests 6. Continue to the next feature
- 14. Test First Test Driven Design main benefits Ensure we didnt break anything We wont break anything
- 15. Test First Test Driven Design collateral benefits Define the types and API early Refine the expectations ASAP Document the API before implementing Can mock the UI before implementing Tests as specification
- 16. Unit Tests
- 17. Unit Tests Validate a single method Sometimes a single class with a few methods Dependencies may be stubbed/mocked This is the first test to write
- 18. Unit Tests Validate a single method - in practice Look for all corner cases, and best coverage Dont hesitate to include loops and fuzzing Some unit tests could be skipped if robust integration tests are involved (e.g. not fixed values, but fuzzed/random content)
- 20. Integration Tests Integrate several classes and methods Favor composition over inheritance Up to a system-wide tests (clients, servers) Can mock/stub some dependencies (e.g. email, DB, third-party library)
- 21. Integration Tests Integrate several classes and methods Triggered locally by the developers (their main application should be the test suite, not the client/UI/mobile application) Include in the build chain (e.g. in a batch file, or a Jenkins/github service) Run in sandboxed or pre-production environment (may use containers)
- 23. Performance Tests Check for execution timing and proper scaling Testing on the developer machine is inconsistent (high-end hardware and local execution) Ensure test environment consistency (e.g. same DB indexes) Not always: performance may not be a concern for some features
- 24. Performance Tests Check for execution timing in practice Log accurate timing on production, then identify real bottlenecks, then write corresponding performance tests, and include them to the Integration Tests / build chain if possible
- 25. mORMot
- 27. mORMot mormot.core.tests.pas Regression tests mormot.core.interfaces.pas Mocks and Stubs
- 28. mORMot Lets look in detail at the /tests/mormot2tests project
- 29. Test Driven Design Questions? No Marmots Were Harmed in the Making of This Session No Marmots Were Harmed in the Making of This Session