Test-Driven Development (TDD) puts testing at the heart of the development process. Instead of testing being a boring, time-compressed flurry of bug hunting that follows on from implementation, TDD sees us use tests to drive and support the implementation process itself. Applied correctly, TDD may lead to better designed, less buggy software that developers are confident to evolve and extend as new requirements arrive.
Participants should be comfortable with Java and its surrounding toolchain
Course material in English included.
It sounds great, but the devil is, as always, in the details: How do we write automated tests? Why is it a good idea to let the tests drive the development? Where do we find the time to test?
Developed by Edument's leading teachers and developers, this course draws on a wealth of real world experiences to show you how to apply TDD. Of course, we'll take you carefully through the practicalities of writing unit tests - but it doesn't stop there. We'll show how tests can aid the design process, how to get more value out of tests, and discuss the properties of good tests as well as pointing out various pitfalls to avoid.
A mix of pertinent theory and demonstrations show the way, and the course labs provide a chance for you to try things out for yourself!
Straight To The Action: A TDD Spoiler
- Opening demonstration of using TDD to add a new feature to a system
- Dissecting the demo: test first, red/green/refactor, regression avoidance
Stepping Back: The Big Picture
- Traditional views of testing, and why they're suboptimal
- What makes TDD different?
- Why red/green/refactor?
- Why not red/green/refactor?
- Types of test
Baby Steps: Basic Unit Testing
- What is JUnit?
- Getting JUnit
- Test fixtures and tests
- The "System Under Test" pattern
- The "Arrange, Act, Assert" pattern
- Exercise on writing basic unit tests
Growing Up: Better Unit Test Design and Implementation
- Factoring out boilerplate with Setup methods
- Considering happy and sad paths
- Errors give you next steps just like successes do
- Testing for exceptions
- Tell, Don't Ask: Avoiding state inspection
- Test method granularity
- Anti-patterns to avoid
- Testing kata
- Other test runners
- The Law of Demeter: Focus on the SUT
- Exercise on writing better unit tests
- What refactoring really is
- Refactor mercilessly
- You Ain't Gonna Need It
- Once And Only Once
- Single Responsibility Principle
- Feature Envy
- Exercise on refactoring
Coping With Dependencies: Mocking, Stubbing and DI
- Why dependencies make testing harder
- The problem with
- The Dependency Inversion solution
- Refactoring to DI
- Stubs vs. mocks
- Stubbing by hand
- Exercise on dependency injection and stubbing
Oh, The Mockery: Mock/Stub Object Frameworks
- Why consider a mock/stub object framework?
- Some of the options
- Stub objects with EasyMock
- Mock objects with EasyMock
- Exercise on using EasyMock
Environmental Issues: Time, UIs, Databases, oh my...
- Taking control of time
- Presentation patterns for testable UIs
- Coping with data access
Higher Order Programming and Testing: IoC without the DI
- Why Inversion of Control is the really interesting thing here
- A quick lambda refresher
- Lambda injection
- Exercise on lambda injection
Functional Influences: Referentially Transparent Business Logic
- What is referential transparency?
- Why is it so desirable when doing automated testing?
- Behavioural testing and BDD
- A command/event/aggregate factoring with behavioural tests
- Exercise on referentially transparent business logic
Where To Put It: Test Organization
- Solution structure
- Unit tests and integration tests
- Organization by system under test
- Organization by specification
A testing mentality: Fitting tests into the process puzzle
- Continuous Integration
- Test Coverage Analysis
- Commit early and often
- Continous Testing
- Continuous review
- Frequent releases