The testing practices of a Jedi

This presentation describes some of the testing practices which a software team should follow and what's the benefits of TDD.

This has been presented in an internal weekly engineering meeting at ezhome

Transcript

1. The testing practices of a Jedi Spiros I. Economakis
2. Agenda • Testing • What is TDD • Purpose of TDD • Lifecycle • Best Practices • TDD + ATDD • TDD + BDD • TDD Benefits and Drawbacks
3. Why do testing at all? Benefits of software testing are enormous, and they have a significant role in entire business. • Quality • Satisfied customers • Bringing Profit • User Experience • Business optimisation
4. How much testing is enough? There can sometimes be many uncertainties regarding what to test. You should always test: - the happy path - the sad path - the what if scenarios (edge cases) BUT still is it enough?
5. “Just Say No to More End-to-End Tests” Google often suggests a 70/20/10 split: • 10% end-to-end tests • 20% integration tests • 70% unit tests By Mike Wacker https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html TDD
6. Testing Anti-Pattern Strategies https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html
7. What is TDD? Test-Driven Development is a process that relies on the repetition of very short development cycle. It is based on the test-first concept of Extreme Programming (XP) that encourages simple design with high level of confidence.
8. T in TDD It’s not only about testing, TDD is also the way we approach the design and it forces us to think about: • Implementation before writing the code • Structure of the code
9. Purpose of TDD The main objective of TDD is a well designed code with tests with two key factors: • Testable code • Enabled refactoring
10. TDD Lifecycle
11. TDD Lifecycle 1. Write a test 2. Run test and see if the it fails 3. Write some code 4. Run test 5. Refactor code 6. Repeat
12. TDD Best Practices TDD Best practices Practices have been separated into following categories: • Naming Conventions • Processes • Development practices • Tools
13. Naming Conventions • Separate the implementation from the test code (different packages) • Place test classes in the same package as implementation ◦ com.ezhome.skywalker (src/main) ◦ com.ezhome.skywalker (src/test) • Use descriptive names for test methods ◦ whenNonNumberIsUsedThenExceptionIsThrown()
14. Processes • Write the test before writing the implementation code • Only write new code when test is failing • Rerun all tests every time implementation code changes • All tests should pass before new test is written • Refactor only after all tests are passing
15. Development Practices • Write the simplest code to pass the test • Write assertions first, act later • Minimize assertions in each test • Do not introduce dependencies between tests • Tests should run fast • Use mocks • Use setup and tear-down methods • Do not use base classes
16. Tools • Code Coverage ◦ JaCoCo ◦ Clover ◦ Cobertura • Continuous Integration ◦ Jenkins ◦ CircleCI ◦ TravisCI ◦ Bamboo
17. TDD and ATDD Test-driven development is related to, but different from acceptance test–driven development (ATDD). TDD is primarily an engineer’s tool to help create a well-written unit of code (function, class, or module) that correctly performs a set of operations. ATDD is a communication tool between the customer, developer, and tester to ensure that the requirements are well-defined. ATDD encompasses acceptance testing, but highlights writing acceptance tests before developers begin coding
18. TDD and ATDD
19. TDD and BDD BDD (behavior-driven development) combines practices from TDD and from ATDD. It includes the practice of writing tests first, but focuses on tests which describe behavior, rather than tests which test a unit of implementation. Recommendation is to use TDD for high “code coverage” and fast feedback and BDD as automated acceptance tests.
20. TDD Benefits • Better design • Allows easy and safe refactoring • Increases quality and test coverage • Makes sure that software is always tested
21. TDD Drawbacks • Initially, it slows down development process • A challenge to learn (discipline, practice, persistence) • Hard to apply to existing legacy code • The test suite itself has to be maintained; tests may not be completely deterministic • Lot’s of misconceptions that keep programmers from learning it.
22. Thanks Questions???