SlideShare a Scribd company logo
TEST DRIVEN DEVELOPMENT
DAVID EHRINGER
This work by David Ehringer is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License
DAVIDEHRINGER.COM
CONTENTS
What Is TDD?
TDD Principals
Tools
Live Coding
Best Practices And Smells
Other (Tips, Resources, BDD, Etc.)
BACKGROUND
What is TDD?
A PERSPECTIVE ON TDD
TDD is Mostly about Design
Gives Confidence
Enables Change
Is Automated
Validates Your Design
Is Documentation By Example
As Well As an Up To Date, “Live”,
And Executable Specification
Provides Rapid Feedback
Quality of Implementation
Quality of Design
Forces Constant Integration
Requires More Discipline
Brings Professionalism to Software
Development
Isn’t The Only Testing You’ll Need
To Do
Developers Write Tests
RESULT
Higher Quality
Flexibility
Readability
Maintainability
Predicability
Simplicity
The Hard Stuff And Surprises Are Tackled Early On
Both Internal And External Quality Are Maintained
A Well-Designed Application
THE BASIC CYCLE
THE THREE LAWS OF TDD
1: You May Not Write Production Code Until You Have
Written A Failing Unit (or Acceptance) Test
2: You May Not Write More Of A Unit (or Acceptance) Test
Than Is Sufficient To Fail, And Compiling Is Failing
3: You May Not Write More Production Code Than Is
Sufficient To Pass The Currently Failing Test
Ever so slightly adapted from Professionalism and Test-Driven
Development by Robert “Uncle Bob” C. Martin
FUNDAMENTAL PRINCIPLES
Think About What You Are Trying To Do
Follow The TDD Cycle And The Three Laws
Never Write New Functionality Without A Failing Test
Continually Make Small, Incremental Changes
Keep The System Running At All Times
No One Can Make A Change That Breaks The System
Failures Must Be Address Immediately
In reality, unwavering adherence the cycle and laws can sometimes be very hard. In my opinion, it
doesn’t always have to be all or nothing (especially when you are just learning). But I’ve found
that when I don’t write tests first, I usually regret it afterwards. Also, TDD isn’t applicable for
every single scenario or line of code.
“TDD IN A NUTSHELL”
As we develop the system, we use TDD to give us feedback on the quality of both its implementation
(“Does it work?”) and design (“Is it well structured?”). Developing test-first, we find we benefit
twice from the effort. Writing Tests:
• makes us clarify the acceptance criteria for the next piece of work - we have to ask ourselves
how we can tell when we’re done (Design);
• encourages us to write loosely coupled components, so they can easily be tested in isolation and,
at higher levels, combined together (Design);
• adds an executable description of what the code does (Design); and,
• adds to a complete regression suite (Implementation)
whereas running tests:
• detects errors while the context is fresh in our mind (Implementation); and,
• lets us know when we’ve done enough, discouraging “gold plating” and unnecessary features
(Design)
From Growing Object-Oriented Software, Guided By Tests
BUT HOW MUCH LONGER DOES TDD
TAKE?
“If it doesn’t have to work, I can get it done a lot
faster!” - Kent Beck paraphrased
My Experience
- Initial Progress Will Be Slower
- Greater Consistency
- Less Experienced Developer Learning/Ramp-up Time
- I personally think I can develop faster using TDD
than without, but it took a while to get there
- Long-term cost is drastically lower
Studies
- Takes 15-30% longer
- 45-90% fewer bugs
- Takes 10x as long to fix a bug in later phases
- One study with Microsoft and IBM: http://
research.microsoft.com/en-us/projects/esm/
nagappan_tdd.pdf
SOME DESIGN PRINCIPALS
Loosely coupled, highly cohesive
Dependency Injection/Inversion of
Control (IOC)
Single Responsibility Principal
Strive for Simplicity
Open/Closed Principal
Law of Demeter (“Tell don’t ask.”)
Modularization
Separation of Concerns
Encapsulation
Favor Immutability
Domain Driven Design
Decentralized Management and
Decision Making
Strict Dependency Management
Clean Code
Ubiquitous Language
Eliminate Duplication
WHAT ABOUT ARCHITECTURE AND
DESIGN?
TDD Does Not Replace Architecture Or Design
You Need To Do Up Front Design And Have A Vision
But, You Should Not Do “Big Up Front Design”
Defer Architectural Decisions As Long As Is “Responsibly” Possible
TDD Will Inform And Validate (or Invalidate) Your Design
Decisions
TDD Will Almost Undoubtedly Uncover Weaknesses And Flaws In
Your Design...Listen To Them!
CATEGORIES OF TESTS
Unit
Integration
Acceptance
Can Encompass “system” Or “functional” Tests
End-to-end Is Desirable When Feasible
Learning Or Exploratory
THE EXTENDED CYCLE
From Growing Object-Oriented Software, Guided By Tests
TOOLS OF THE TRADE
Unit Test Framework
Mocking Framework
Automated Build Tool
Acceptance Test Framework (often The Same As The Unit Test Framework)
Source Code Management
Build And Continuous Integration Servers
Test Coverage Tools
Code Quality Tools
For Java-based Apps, Consider Using A Dynamic Language (e.g. Groovy) To Write Tests If
You Are Comfortable With It
TOOLS OF THE TRADE -
RECOMMENDATIONS
Unit Test Framework - JUnit 4, Hamcrest Matchers Are Recommended For
Improved Readability And Expressiveness
Mocking Framework - Mockito
Automated Build Tool - Maven
Acceptance Test Framework - Web Services: SoapUI, Web App: Selenium
Source Code Management - Depends On The Project Needs
Continuous Integration - Bamboo Is Nice, Should Be Simple And Easy To Use And
Support Your Build Tool
Test Coverage Tools - Cobertura Or Clover (soapUI Pro For Web Services)
Code Quality Tools - PMD, FindBugs, Checkstyle
SOME NOTES ON YOUR BUILD
Should Be Fully Automated
Should Run Anywhere And Be Decoupled From The IDE
You Should Be Able To Build Your Artifact In One Command
“mvn package”
You Should Be Able To Run Your Unit Tests In One Command
“mvn test”
You Should Be Able To Run You Acceptance Tests In One Command
“mvn integration-test”
Test Coverage And Code Quality Tools Should Be Integrated Into The Build
BUILD PIPELINE
MAVEN BUILD LIFECYCLE
MOCKING
Limit The Scope Of Your Test To The Object Under Test
Mocks Mimic The Behavior Of Objects (the Dependencies Of
Your Object Under Test) In Predictable Ways
Mocks Contains Assertions Themselves
Prefer Mocking Of Behavior Rather Than Data (strictly
Stubs)
Be Careful: Mocks Can Couple The Test To The Underlying
Implementation Of The Code Being Tested
TDD BY EXAMPLE
Time For Some Live Coding
BUT FIRST... A FEW MORE WORDS
Iteration 0/Walking Skeleton
Build, Deploy, Test End-to-end
Includes Process As Well As Infrastructure
THE EXAMPLE
A Trivial Customer Management App
Web-service, Business Logic, Database
Starts With A Full, Walking Skeleton
BACK TO THE EXAMPLES
Starting With An Acceptance Test
Unit Tests To Fill In The Details
Refactoring Along The Way
Components/Modules And Large Projects
CODE COVERAGE AND QUALITY TOOLS
NON-LIVE EXAMPLES
Learning/Exploratory
Mocking
Test Data Builders
Others?
BEST PRACTICES: F.I.R.S.T
Fast
Independent
Repeatable
Self-validating
Timely
From Object Mentor, www.objectmentor.com
SPEED: TRADITIONAL DEVELOPMENT
• 5 mins per coding hour becomes 6000
minutes annually (2.5, 40-hour
workweeks)
• 9 mins per coding hour becomes 10800
minutes annually (4.5 weeks)
• 14 mins per coding hour becomes
16800 mins annually (7 weeks)
Survey by ZeroTurnaround
http://www.zeroturnaround.com/blog/java-ee-
container-redeploy-restart-turnaround-report/
SPEED IS CRITICAL
Developers Need Immediate Feedback
Tests Must Run Fast
Consider Using Jetty And HSQLDB For Automated Unit And
Acceptance Testing
Depending On Your Framework, It Can Be Easy To Use Jetty/
HSQLDB For Local Development And Automated Testing And
Deploy To Websphere/Oracle In “Real” Environments
Make Sure You Do Continuous And Early Integration
BEST PRACTICES: CONSISTENCY
Test Environments Should Be Scripted And Consistent
Test Data Should Be Scripted And Consistent
Database
In-memory Databases
Fast
Reliable
Easily Scriptable
HSQLDB
Messaging
ActiveMQ Is A Good Alternative For Tests
Simple To Set Up
BEST PRACTICES: TEST NAMING AND
STRUCTURE
The Name Of The Test Should Describe A Feature Or Specification
The Name Should Clearly Describe The Purpose Of The Test
Frequently Read The Test Documentation
Each Test Should Be For A Single Concept
Strive For One Assertion Per Test
Or As Few As Possible
More Than One May Indicate More Than One Concept Is Being Tested
What Does The Object Do, Not What Is The Object
BEST PRACTICES
Only Specify What Is Important
Even Seemingly Trivial Tests Are Important
Treat Your Test Code Like Production Code
Maintain
Refactor
Expressiveness And Readability Of Tests
Check In To Source Control Frequently
Consistent Test Structure
Setup/Execute/Verify/Teardown
Given/When/Then
BEST PRACTICES: MANAGING TEST DATA
Objects
Avoid Mocking Values
Test Data Builders
Persistent
In-memory Database
Scripted Data
SMELLS
Doing The Opposite Of The Best Practices :-)
Just Making It Work Isn’t Good Enough
Should Be Able To Run Tests Independently
Tests Should Never Depend On Each Other
TIPS: ECLIPSE SHORTCUTS RELATED TO
TESTING
Ctrl+1: Quick Fix
Ctrl+Shift+X, T : Run As Unit Test (Use In Any Context: Method, Class, Package,
Project, Etc.)
F11: Launch Last Test
F3: Open Declaration
Alt+Shift+3: Refactoring Menu
Alt+Shift+S: Code Completion/Generation/Format Menu
Ctrl+e: Switch Between Open Windows
Eclipse Static Import Favorites
These are Windows specific. On Mac you usually,
but not always, substitute Command for Ctrl
TIPS: SOME OTHER ECLIPSE SHORTCUTS
Ctrl-Space: Code Completion
Ctrl-Shift-F: Format Code
Ctrl-Shift-O: Organize Import
Ctrl-Shift-T: Open Type
Ctrl-Shift-R: Open Resource
Ctrl-/: Toggle Comment
Ctrl-Shift-W: Close All Open Windows
Ctrl-N: New Wizard
Ctrl-F7: Move Between Open Views
Ctrl+Shift+L: Show Shortcuts
Alt+left, Alt+right: Toggle Windows
TDD CHALLENGES
Discipline Is Required
Developers Are Often Stubborn And Lazy
It Is Hard For Developers To Drop Bad Habits
Management Doesn’t Often Understand “Internal Quality”
SOME RESOURCES RELATED TO TDD
Should Be On Every Professional Developers Bookshelf
Refactoring (Fowler)
Domain Driven Design (Evans)
Clean Code (“Uncle Bob” Martin)
Recommended
Growing Object-Oriented Software, Guided By Tests (Freeman, Pryce)
Implementation Patterns (Beck)
Haven’t Read But, Given The Authors, Should Be Good
Test Driven Development: By Example (Beck)
The Book That “Rediscovered” TDD
XUnit Patterns (Meszaros)
By No Means An Exhaustive List But Should Keep You Busy For A While
BEHAVIOR DRIVEN DEVELOPMENT
“TDD Done Right”
Stories And Specifications
Ubiquitous Language
Given/When/Then
Should/Ensure
easyb (Groovy) Is Nice If You Are Working In The Java
World

More Related Content

PPS
Unit Testing
PPT
TDD (Test Driven Design)
PPTX
TDD - Test Driven Development
PDF
An Introduction to Test Driven Development
PDF
Unit testing best practices
PPTX
Understanding Unit Testing
PDF
How To Write A Test Case In Software Testing | Edureka
PDF
Unit and integration Testing
Unit Testing
TDD (Test Driven Design)
TDD - Test Driven Development
An Introduction to Test Driven Development
Unit testing best practices
Understanding Unit Testing
How To Write A Test Case In Software Testing | Edureka
Unit and integration Testing

What's hot (20)

PPTX
TDD - Agile
PPTX
Agile Testing and Test Automation
PDF
Test Driven Development
PPTX
Unit testing & TDD concepts with best practice guidelines.
PPTX
Test-Driven Development
PPT
Manual testing ppt
PPT
Test Driven Development
PPT
Test Automation Framework Designs
PDF
TDD and BDD and ATDD
PPT
Selenium ppt
PDF
PPTX
Software testing
PPT
Test Automation Best Practices (with SOA test approach)
PPT
Basic software-testing-concepts
PPT
Manual testing concepts course 1
PPTX
UNIT TESTING PPT
PPTX
PPTX
Introduction to Automation Testing
PDF
Test Automation Framework Design | www.idexcel.com
PPTX
Test Driven Development
TDD - Agile
Agile Testing and Test Automation
Test Driven Development
Unit testing & TDD concepts with best practice guidelines.
Test-Driven Development
Manual testing ppt
Test Driven Development
Test Automation Framework Designs
TDD and BDD and ATDD
Selenium ppt
Software testing
Test Automation Best Practices (with SOA test approach)
Basic software-testing-concepts
Manual testing concepts course 1
UNIT TESTING PPT
Introduction to Automation Testing
Test Automation Framework Design | www.idexcel.com
Test Driven Development
Ad

Similar to Test Driven Development (TDD) (20)

PPTX
TDD in Agile
PPTX
Test driven development v1.0
PDF
Test-Driven Developments are Inefficient; Behavior-Driven Developments are a ...
PPT
Unit Testing, TDD and the Walking Skeleton
PDF
Test Driven Development Methodology and Philosophy
PDF
Developers’ mDay u Banjoj Luci - Milan Popović, PHP Srbija – Testimony (about...
PPTX
A Brief Introduction to Test-Driven Development
PDF
Test driven development
PPTX
Understanding TDD - theory, practice, techniques and tips.
PDF
Growing Object Oriented Software
PPTX
An Introduction To Software Development - Test Driven Development, Part 1
PPTX
2015 msu-code-review
PDF
Hey You Got Your TDD in my SQL DB by Jeff McKenzie
PDF
Test Driven Development
PPTX
TDD - Seriously, try it - Codemotion (May '24)
PDF
Test-Driven Development Reference Card
PPTX
Test Driven Development on Android (Kotlin Kenya)
PPTX
Test-Driven Development In Action
PDF
Test driven development : software process
TDD in Agile
Test driven development v1.0
Test-Driven Developments are Inefficient; Behavior-Driven Developments are a ...
Unit Testing, TDD and the Walking Skeleton
Test Driven Development Methodology and Philosophy
Developers’ mDay u Banjoj Luci - Milan Popović, PHP Srbija – Testimony (about...
A Brief Introduction to Test-Driven Development
Test driven development
Understanding TDD - theory, practice, techniques and tips.
Growing Object Oriented Software
An Introduction To Software Development - Test Driven Development, Part 1
2015 msu-code-review
Hey You Got Your TDD in my SQL DB by Jeff McKenzie
Test Driven Development
TDD - Seriously, try it - Codemotion (May '24)
Test-Driven Development Reference Card
Test Driven Development on Android (Kotlin Kenya)
Test-Driven Development In Action
Test driven development : software process
Ad

Recently uploaded (20)

PDF
CIFDAQ's Market Insight: SEC Turns Pro Crypto
PDF
Electronic commerce courselecture one. Pdf
PPTX
VMware vSphere Foundation How to Sell Presentation-Ver1.4-2-14-2024.pptx
PDF
Build a system with the filesystem maintained by OSTree @ COSCUP 2025
PPTX
MYSQL Presentation for SQL database connectivity
PDF
Empathic Computing: Creating Shared Understanding
PDF
NewMind AI Monthly Chronicles - July 2025
PDF
Advanced Soft Computing BINUS July 2025.pdf
PDF
Peak of Data & AI Encore- AI for Metadata and Smarter Workflows
PDF
Machine learning based COVID-19 study performance prediction
PDF
How UI/UX Design Impacts User Retention in Mobile Apps.pdf
PDF
Optimiser vos workloads AI/ML sur Amazon EC2 et AWS Graviton
PDF
Diabetes mellitus diagnosis method based random forest with bat algorithm
PPTX
Big Data Technologies - Introduction.pptx
PDF
Blue Purple Modern Animated Computer Science Presentation.pdf.pdf
PDF
Dropbox Q2 2025 Financial Results & Investor Presentation
PDF
Modernizing your data center with Dell and AMD
PDF
Shreyas Phanse Resume: Experienced Backend Engineer | Java • Spring Boot • Ka...
PDF
Spectral efficient network and resource selection model in 5G networks
PDF
KodekX | Application Modernization Development
CIFDAQ's Market Insight: SEC Turns Pro Crypto
Electronic commerce courselecture one. Pdf
VMware vSphere Foundation How to Sell Presentation-Ver1.4-2-14-2024.pptx
Build a system with the filesystem maintained by OSTree @ COSCUP 2025
MYSQL Presentation for SQL database connectivity
Empathic Computing: Creating Shared Understanding
NewMind AI Monthly Chronicles - July 2025
Advanced Soft Computing BINUS July 2025.pdf
Peak of Data & AI Encore- AI for Metadata and Smarter Workflows
Machine learning based COVID-19 study performance prediction
How UI/UX Design Impacts User Retention in Mobile Apps.pdf
Optimiser vos workloads AI/ML sur Amazon EC2 et AWS Graviton
Diabetes mellitus diagnosis method based random forest with bat algorithm
Big Data Technologies - Introduction.pptx
Blue Purple Modern Animated Computer Science Presentation.pdf.pdf
Dropbox Q2 2025 Financial Results & Investor Presentation
Modernizing your data center with Dell and AMD
Shreyas Phanse Resume: Experienced Backend Engineer | Java • Spring Boot • Ka...
Spectral efficient network and resource selection model in 5G networks
KodekX | Application Modernization Development

Test Driven Development (TDD)

  • 1. TEST DRIVEN DEVELOPMENT DAVID EHRINGER This work by David Ehringer is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License DAVIDEHRINGER.COM
  • 2. CONTENTS What Is TDD? TDD Principals Tools Live Coding Best Practices And Smells Other (Tips, Resources, BDD, Etc.)
  • 5. A PERSPECTIVE ON TDD TDD is Mostly about Design Gives Confidence Enables Change Is Automated Validates Your Design Is Documentation By Example As Well As an Up To Date, “Live”, And Executable Specification Provides Rapid Feedback Quality of Implementation Quality of Design Forces Constant Integration Requires More Discipline Brings Professionalism to Software Development Isn’t The Only Testing You’ll Need To Do Developers Write Tests
  • 6. RESULT Higher Quality Flexibility Readability Maintainability Predicability Simplicity The Hard Stuff And Surprises Are Tackled Early On Both Internal And External Quality Are Maintained A Well-Designed Application
  • 8. THE THREE LAWS OF TDD 1: You May Not Write Production Code Until You Have Written A Failing Unit (or Acceptance) Test 2: You May Not Write More Of A Unit (or Acceptance) Test Than Is Sufficient To Fail, And Compiling Is Failing 3: You May Not Write More Production Code Than Is Sufficient To Pass The Currently Failing Test Ever so slightly adapted from Professionalism and Test-Driven Development by Robert “Uncle Bob” C. Martin
  • 9. FUNDAMENTAL PRINCIPLES Think About What You Are Trying To Do Follow The TDD Cycle And The Three Laws Never Write New Functionality Without A Failing Test Continually Make Small, Incremental Changes Keep The System Running At All Times No One Can Make A Change That Breaks The System Failures Must Be Address Immediately In reality, unwavering adherence the cycle and laws can sometimes be very hard. In my opinion, it doesn’t always have to be all or nothing (especially when you are just learning). But I’ve found that when I don’t write tests first, I usually regret it afterwards. Also, TDD isn’t applicable for every single scenario or line of code.
  • 10. “TDD IN A NUTSHELL” As we develop the system, we use TDD to give us feedback on the quality of both its implementation (“Does it work?”) and design (“Is it well structured?”). Developing test-first, we find we benefit twice from the effort. Writing Tests: • makes us clarify the acceptance criteria for the next piece of work - we have to ask ourselves how we can tell when we’re done (Design); • encourages us to write loosely coupled components, so they can easily be tested in isolation and, at higher levels, combined together (Design); • adds an executable description of what the code does (Design); and, • adds to a complete regression suite (Implementation) whereas running tests: • detects errors while the context is fresh in our mind (Implementation); and, • lets us know when we’ve done enough, discouraging “gold plating” and unnecessary features (Design) From Growing Object-Oriented Software, Guided By Tests
  • 11. BUT HOW MUCH LONGER DOES TDD TAKE? “If it doesn’t have to work, I can get it done a lot faster!” - Kent Beck paraphrased My Experience - Initial Progress Will Be Slower - Greater Consistency - Less Experienced Developer Learning/Ramp-up Time - I personally think I can develop faster using TDD than without, but it took a while to get there - Long-term cost is drastically lower Studies - Takes 15-30% longer - 45-90% fewer bugs - Takes 10x as long to fix a bug in later phases - One study with Microsoft and IBM: http:// research.microsoft.com/en-us/projects/esm/ nagappan_tdd.pdf
  • 12. SOME DESIGN PRINCIPALS Loosely coupled, highly cohesive Dependency Injection/Inversion of Control (IOC) Single Responsibility Principal Strive for Simplicity Open/Closed Principal Law of Demeter (“Tell don’t ask.”) Modularization Separation of Concerns Encapsulation Favor Immutability Domain Driven Design Decentralized Management and Decision Making Strict Dependency Management Clean Code Ubiquitous Language Eliminate Duplication
  • 13. WHAT ABOUT ARCHITECTURE AND DESIGN? TDD Does Not Replace Architecture Or Design You Need To Do Up Front Design And Have A Vision But, You Should Not Do “Big Up Front Design” Defer Architectural Decisions As Long As Is “Responsibly” Possible TDD Will Inform And Validate (or Invalidate) Your Design Decisions TDD Will Almost Undoubtedly Uncover Weaknesses And Flaws In Your Design...Listen To Them!
  • 14. CATEGORIES OF TESTS Unit Integration Acceptance Can Encompass “system” Or “functional” Tests End-to-end Is Desirable When Feasible Learning Or Exploratory
  • 15. THE EXTENDED CYCLE From Growing Object-Oriented Software, Guided By Tests
  • 16. TOOLS OF THE TRADE Unit Test Framework Mocking Framework Automated Build Tool Acceptance Test Framework (often The Same As The Unit Test Framework) Source Code Management Build And Continuous Integration Servers Test Coverage Tools Code Quality Tools For Java-based Apps, Consider Using A Dynamic Language (e.g. Groovy) To Write Tests If You Are Comfortable With It
  • 17. TOOLS OF THE TRADE - RECOMMENDATIONS Unit Test Framework - JUnit 4, Hamcrest Matchers Are Recommended For Improved Readability And Expressiveness Mocking Framework - Mockito Automated Build Tool - Maven Acceptance Test Framework - Web Services: SoapUI, Web App: Selenium Source Code Management - Depends On The Project Needs Continuous Integration - Bamboo Is Nice, Should Be Simple And Easy To Use And Support Your Build Tool Test Coverage Tools - Cobertura Or Clover (soapUI Pro For Web Services) Code Quality Tools - PMD, FindBugs, Checkstyle
  • 18. SOME NOTES ON YOUR BUILD Should Be Fully Automated Should Run Anywhere And Be Decoupled From The IDE You Should Be Able To Build Your Artifact In One Command “mvn package” You Should Be Able To Run Your Unit Tests In One Command “mvn test” You Should Be Able To Run You Acceptance Tests In One Command “mvn integration-test” Test Coverage And Code Quality Tools Should Be Integrated Into The Build
  • 21. MOCKING Limit The Scope Of Your Test To The Object Under Test Mocks Mimic The Behavior Of Objects (the Dependencies Of Your Object Under Test) In Predictable Ways Mocks Contains Assertions Themselves Prefer Mocking Of Behavior Rather Than Data (strictly Stubs) Be Careful: Mocks Can Couple The Test To The Underlying Implementation Of The Code Being Tested
  • 22. TDD BY EXAMPLE Time For Some Live Coding
  • 23. BUT FIRST... A FEW MORE WORDS Iteration 0/Walking Skeleton Build, Deploy, Test End-to-end Includes Process As Well As Infrastructure
  • 24. THE EXAMPLE A Trivial Customer Management App Web-service, Business Logic, Database Starts With A Full, Walking Skeleton
  • 25. BACK TO THE EXAMPLES Starting With An Acceptance Test Unit Tests To Fill In The Details Refactoring Along The Way Components/Modules And Large Projects
  • 26. CODE COVERAGE AND QUALITY TOOLS
  • 29. SPEED: TRADITIONAL DEVELOPMENT • 5 mins per coding hour becomes 6000 minutes annually (2.5, 40-hour workweeks) • 9 mins per coding hour becomes 10800 minutes annually (4.5 weeks) • 14 mins per coding hour becomes 16800 mins annually (7 weeks) Survey by ZeroTurnaround http://www.zeroturnaround.com/blog/java-ee- container-redeploy-restart-turnaround-report/
  • 30. SPEED IS CRITICAL Developers Need Immediate Feedback Tests Must Run Fast Consider Using Jetty And HSQLDB For Automated Unit And Acceptance Testing Depending On Your Framework, It Can Be Easy To Use Jetty/ HSQLDB For Local Development And Automated Testing And Deploy To Websphere/Oracle In “Real” Environments Make Sure You Do Continuous And Early Integration
  • 31. BEST PRACTICES: CONSISTENCY Test Environments Should Be Scripted And Consistent Test Data Should Be Scripted And Consistent Database In-memory Databases Fast Reliable Easily Scriptable HSQLDB Messaging ActiveMQ Is A Good Alternative For Tests Simple To Set Up
  • 32. BEST PRACTICES: TEST NAMING AND STRUCTURE The Name Of The Test Should Describe A Feature Or Specification The Name Should Clearly Describe The Purpose Of The Test Frequently Read The Test Documentation Each Test Should Be For A Single Concept Strive For One Assertion Per Test Or As Few As Possible More Than One May Indicate More Than One Concept Is Being Tested What Does The Object Do, Not What Is The Object
  • 33. BEST PRACTICES Only Specify What Is Important Even Seemingly Trivial Tests Are Important Treat Your Test Code Like Production Code Maintain Refactor Expressiveness And Readability Of Tests Check In To Source Control Frequently Consistent Test Structure Setup/Execute/Verify/Teardown Given/When/Then
  • 34. BEST PRACTICES: MANAGING TEST DATA Objects Avoid Mocking Values Test Data Builders Persistent In-memory Database Scripted Data
  • 35. SMELLS Doing The Opposite Of The Best Practices :-) Just Making It Work Isn’t Good Enough Should Be Able To Run Tests Independently Tests Should Never Depend On Each Other
  • 36. TIPS: ECLIPSE SHORTCUTS RELATED TO TESTING Ctrl+1: Quick Fix Ctrl+Shift+X, T : Run As Unit Test (Use In Any Context: Method, Class, Package, Project, Etc.) F11: Launch Last Test F3: Open Declaration Alt+Shift+3: Refactoring Menu Alt+Shift+S: Code Completion/Generation/Format Menu Ctrl+e: Switch Between Open Windows Eclipse Static Import Favorites These are Windows specific. On Mac you usually, but not always, substitute Command for Ctrl
  • 37. TIPS: SOME OTHER ECLIPSE SHORTCUTS Ctrl-Space: Code Completion Ctrl-Shift-F: Format Code Ctrl-Shift-O: Organize Import Ctrl-Shift-T: Open Type Ctrl-Shift-R: Open Resource Ctrl-/: Toggle Comment Ctrl-Shift-W: Close All Open Windows Ctrl-N: New Wizard Ctrl-F7: Move Between Open Views Ctrl+Shift+L: Show Shortcuts Alt+left, Alt+right: Toggle Windows
  • 38. TDD CHALLENGES Discipline Is Required Developers Are Often Stubborn And Lazy It Is Hard For Developers To Drop Bad Habits Management Doesn’t Often Understand “Internal Quality”
  • 39. SOME RESOURCES RELATED TO TDD Should Be On Every Professional Developers Bookshelf Refactoring (Fowler) Domain Driven Design (Evans) Clean Code (“Uncle Bob” Martin) Recommended Growing Object-Oriented Software, Guided By Tests (Freeman, Pryce) Implementation Patterns (Beck) Haven’t Read But, Given The Authors, Should Be Good Test Driven Development: By Example (Beck) The Book That “Rediscovered” TDD XUnit Patterns (Meszaros) By No Means An Exhaustive List But Should Keep You Busy For A While
  • 40. BEHAVIOR DRIVEN DEVELOPMENT “TDD Done Right” Stories And Specifications Ubiquitous Language Given/When/Then Should/Ensure easyb (Groovy) Is Nice If You Are Working In The Java World