Test-Driven Development: Extensive Tutorial
Free!
Minimum price
$10.00
Suggested price
This book is 40% complete
Last updated on 2018-10-17
About the Book
This ebook is an attempt to create open-source extensive tutorial on Test-Driven Development.
Source code is at https://github.com/grzesiek-galezowski/tdd-ebook
This book is and always will be free.
License
About the Author
About the Contributors
Cover Designer
Author of lest, A modern, C++11-native, header-only, tiny framework for unit-tests, TDD and BDD, https://github.com/martinmoene/lest
Table of Contents
-
Front Matter
- Dedications
- Thanks!
-
About code examples
- Notes for C# users
- Notes for Java users
-
Part 1: Just the basics
-
Motivation – the first step to learning TDD
- What TDD feels like
- Let’s get it started!
-
The essential tools
- Test framework
- Mocking framework
- Anonymous values generator
- Summary
-
It’s not (only) a test
- When a test becomes something more
- Taking it to the software development land
- A Specification rather than a test suite
- The differences between executable and “traditional” specifications
-
Statement-first programming
- What’s the point of writing a specification after the fact?
- “Test-First” means seeing a failure
- “Test-After” often ends up as “Test-Never”
- “Test-After” often leads to design rework
- Summary
-
Practicing what we have already learned
- Let me tell you a story
- Act 1: The Car
- Act 2: The Customer’s Site
- Act 3: Test-Driven Development
- Epilogue
- Sorting out the bits
-
How to start?
- Start with a good name
- Start by filling the GIVEN-WHEN-THEN structure with the obvious
- Start from the end
- Start by invoking a method if you have one
- Summary
-
How is TDD about analysis and what does “GIVEN-WHEN-THEN” mean?
- Is there really a commonality between analysis and TDD?
- Gherkin
- TODO list… again!
-
What is the scope of a unit-level Statement in TDD?
- Scope and level
- On what level do we specify our software?
- What should be the functional scope of a single Statement?
- Failing to adhere to the three rules
- How many assertions do I need?
- Summary
-
Developing a TDD style and Constrained Non-Determinism
- A style?
- Principle: Tests As Specification
- First technique: Anonymous Input
- Second technique: Derived Values
- Third technique: Distinct Generated Values
- Fourth technique: Constant Specification
- Summary of the example
- Constrained non-determinism
- Summary
-
Specifying functional boundaries and conditions
- Sometimes, an anonymous value is not enough
- Exceptions to the rule
- Rules valid within boundaries
- Combination of boundaries – ranges
- Summary
-
Driving the implementation from Specification
- Type the obvious implementation
- Fake it (‘til you make it)
- Triangulate
- Summary
-
Motivation – the first step to learning TDD
-
Part 2: Object-Oriented World
-
On Object Composability
- Another task for Johnny and Benjamin
- A Quick Retrospective
-
Telling, not asking
- Contractors
- A Quick Retrospective
-
The need for mock objects
- Composability… again!
-
Why do we need composability?
- Pre-object-oriented approaches
- Object-oriented programming to the rescue!
- The power of composition
- Summary – are you still with me?
-
Web, messages and protocols
- So, again, what does it mean to compose objects?
- Alarms, again!
- Summary
-
Composing a web of objects
- Three important questions
- A preview of all three answers
- When are objects composed?
-
How does a sender obtain a reference to a recipient (i.e. how connections are made)?
- Receive as constructor parameter
- Receive inside a message (i.e. as a method parameter)
- Receive in response to a message (i.e. as method return value)
- Receive as a registered observer
-
Where are objects composed?
- Composition Root
- Factories
- Summary
-
Interfaces
- Classes vs interfaces
- Events/callbacks vs interfaces – few words on roles
- Small interfaces
-
Protocols
- Protocols exist
- Protocol stability
- Craft messages to reflect sender’s intention
- Model interactions after the problem domain
- Message recipients should be told what to do, instead of being asked for information
- Most of the getters should be removed, return values should be avoided
- Protocols should be small and abstract
- Summary
-
Classes
- Single Responsibility Principle
- Static recipients
- Summary
-
Object Composition as a Language
- More readable composition root
- Refactoring for readability
- Composition as a language
- The significance of a higher-level language
- Some advice
- Summary
-
Value Objects
- What is a value?
- Example: money and names
-
Value object anatomy
- Class signature
- Hidden data
- Hidden constructor
- String conversion methods
- Equality members
- The return of investment
- Summary
-
Aspects of value objects design
- Immutability
- Handling of variability
- Special values
- Value types and Tell Don’t Ask
- Summary
-
On Object Composability
-
Part 3: TDD in Object-Oriented World
-
Mock Objects as a testing tool
- A backing example
- Interfaces
- Protocols
- Roles
- Behaviors
- Filling in the roles
- Using a mock channel
- Mocks as yet another context
- Summary
-
Test-first using mock objects
- How to start? – with mock objects
- Responsibility and Responsibility
- Channel and DataDispatch one more time
- The first behavior
- Second behavior – specifying an error
- Summary
- THIS IS ALL I HAVE FOR NOW. WHAT FOLLOWS IS RAW, UNORDERED MATERIAL THAT’S NOT YET READY TO BE CONSUMED AS PART OF THIS TUTORIAL
-
Test-driving at the input boundary
- Fixing the ticket office
- Initial objects
- Bootstrap
- Starting the first Statement
- Test-driving at the input boundary - a retrospective
-
Mock objects as a design tool
- Outside-in development
- Worked example
- Programming by intention
- Responsibility-Driven Design
- Specifying factories
-
What not to mock?
- Internals
- How to use value objects in Statements?
- How to specify value objects?
- Terminal nodes in object graph
-
Guidance of test smells
- Long Statements
- Lots of stubbing
- Specifying private members
- Mocking third party
-
Revisiting topics from chapter 1
- Constrained non-determinism in OO world
- Behavioral boundaries
- Triangulation
-
Maintainable mock-based Statements
- Setup and teardown
- Refactoring mock code
-
Mock Objects as a testing tool
-
Part 4: Application architecture
- On stable/architectural boundaries
-
Ports and adapters
- Physical separation of layers
-
What goes into application?
- Application and other layers
-
What goes into ports?
- Data transfer objects
- Ports are not a layer
-
Part 5: TDD on application architecture level
-
Designing automation layer
- Adapting screenplay pattern
- Driver
- Actors
- Data builders
-
Further Reading
- Motivation – the first step to learning TDD
- The Essential Tools
- Value Objects
-
Designing automation layer
- Notes
The Leanpub 45-day 100% Happiness Guarantee
Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms...
