KEMBAR78
Unit Testing, TDD and ATDD | PPTX
©ArnonAxelrod,E4DSolutionsLtd.
UNIT TESTING, TDD
& ATDD
Arnon Axelrod, E4D Solutions
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
About me
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
About you
• Position: Dev, Test, Product,
Management, other?
• TDD/Unit testing experience
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Why Learn TDD Today?
Adoption (% of
martket)
time
Today
ATDD
TDD
Agile
Object-
Oriented
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
TDD?!
Photo by: Stuart Miles
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Learning TDD is like learning to ride a bicycle
©ArnonAxelrod,E4DSolutionsLtd.
Quality
Testing
Unit Tests
TDD
ATDD
©ArnonAxelrod,E4DSolutionsLtd.
Quality throughout the
project lifecycle
What is quality?
Why it is important?
Quality
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Quality
No bugs
Stability
Testing
Design
Happy, Loyal customers
User eXperience
Clean code
Maintainability
Customer feedback
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
The Productivity Misconception
Productivity
Features
Happy customers
MaintainabilityPressure
Legend:
Positive
relationship
Negative
relationship
Increased
Decreased
Productivity
Features
Happy customers
Stability
Clean code
Testing
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
The Productivity Misconception
Productivity
Features
Happy customers
MaintainabilityPressure
Legend:
Positive
relationship
Negative
relationship
Increased
Decreased
Stability
Clean code
Testing
©ArnonAxelrod,E4DSolutionsLtd.
Quality
Testing
Unit Tests
TDD
ATDD
©ArnonAxelrod,E4DSolutionsLtd.
Testing
Testing
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Types of Tests
Exploratory
Planned
Manual
Automated
White box Black box
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Types of Tests
End-to-End
UI
View Model
Client Logic
Server Proxy
Service Layer
Business Logic
DAL
ORM
DB
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Types of Tests
UI
View Model
Client Logic
Server Proxy
Service Layer
Business Logic
DAL
ORM
DB
Usability, UX
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Types of Tests
UI
View Model
Client Logic
Server Proxy
Service Layer
Business Logic
DAL
ORM
DB
Integration
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Types of Tests
UI
View Model
Client Logic
Server Proxy
Service Layer
Business Logic
DAL
ORM
DB
Functional
Mock
Mock
Mock
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Types of Tests
UI
View Model
Client Logic
Server Proxy
Service Layer
DAL
ORM
DB
Unit tests
Business Logic
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Types of tests
• Other:
– Performance
– Load (scalability)
– Install (deployment)
– Monkey testing
©ArnonAxelrod,E4DSolutionsLtd.
Quality
Testing
Unit Tests
TDD
ATDD
©ArnonAxelrod,E4DSolutionsLtd.
Unit tests basics
Unit
Tests
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
What’s a unit test?
• What’s a unit?
– Smallest testable functionality
– any testable functionality (BDD)
• Automatic
• Gray box
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Benefits of Unit Tests
• Fast
• Easy to write and maintain
• Code coverage
• When fail, provide insight into the problem
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Unit tests should:
• Be Isolated
– Re-runnable
• No side effects
• Cleanup
– Environment agnostic
– Order doesn’t matter
• Verify functionality, not implementation
• Be straight-forward
– No conditionals, loops etc
Photo by: tongdang
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Unit tests should:
• Read like a story
• Verify only one thing
• Have meaningful names
• Be fast!
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Inventory class
+int GetAvailablePieces (Item item)
+void Reduce(Item item, int count)
- DbConnectionProvider
Doubles
(mocks)
Order class
+Items
+bool CheckAvailability (IInventory inventory)
+void Supply (IInventory inventory)
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Doubles
(mocks)
Order class
+Items
+bool CheckAvailability (IInventory inventory)
+void Supply (IInventory inventory)
IInventory interface
+int GetAvailablePieces (Item item)
+void Reduce(Item item, int count)
InventoryDouble
+int GetAvailablePieces (Item item)
+void Reduce(Item item, int count)
Inventory class
+int GetAvailablePieces (Item item)
+void Reduce(Item item, int count)
- DbConnectionProvider
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Doubles...
Double
Fake
Dummy MockStub
Detour
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Unit test structure
Arrange Act Assert
Given When Then
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Test suite
Suite Initialize
Test Initialize
Test Method 1
Test Cleanup
Suite Cleanup
Test Method 2 Test Method 3
©ArnonAxelrod,E4DSolutionsLtd.
Quality
Testing
Unit Tests
TDD
ATDD
©ArnonAxelrod,E4DSolutionsLtd.
TDD
TDD
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
What TDD is all about?
Testing?!
Design!
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Why it is important to test First?
• Looking at the problem space
– vs. the solution (implementation) space
• Building decoupled code from base
• Psychological effect
• Testing the test first!
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Testing the Test First!
• What are the inputs?
• What are the outputs?
[TestMethod]
public void TestFibonacciFunction()
{
// arrange
...
// Act:
var result = Fibonacci(...);
// Assert:
Assert ...
}
The test we
want to test
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Testing the Test First!
public bool TestFibonacciFunction(Func<…> fibonacci)
{
// arrange
...
// Act:
var result = fibonacci(...);
// Assert:
return ...
}
The test we
want to test
public void TestTheTest()
{
var invalidImpl = …
var goodImpl = Fibonacci;
Assert.IsFalse(TestFibonacciFunction(invalidImpl));
Assert.IsTrue(TestFibonacciFunction(goodImpl));
}
Testing the test
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
The way TDD works:
Write a
failing test
Write the
code to
make this
test pass
Refactor
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Write a
test
New
Test
Old Tests
Write
production
code
All
Tests
Refactor
All
Tests
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
TDD and Refactoring
Photo by: Chaiwat
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
TDD and Refactoring
public class SomeClass
{
public SomeClass()
{
//...
}
public void Foo(int someParam)
{
// use someParam...
}
}
Initial state
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
TDD and Refactoring
public class SomeClass
{
private int _someParam;
public SomeClass(int someParam)
{
//...
_someParam = someParam;
}
public void Foo()
{
// use _someParam...
}
}
Final (desired)
state
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
TDD and Refactoring
public class SomeClass
{
public SomeClass()
{
//...
}
public void Foo(int someParam)
{
// use someParam...
}
}
Initial state
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
TDD and Refactoring
public class SomeClass
{
public SomeClass()
{
//...
}
private int _someParam;
public SomeClass(int someParam) : this()
{
_someParam = someParam;
}
public void Foo(int someParam)
{
//use someParam...
}
}
Step1 – Add
constructor
overload
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
TDD and Refactoring
public class SomeClass
{
private int _someParam;
public SomeClass(int someParam)
{
//...
_someParam = someParam;
}
public void Foo(int someParam)
{
//use someParam...
}
}
Step2 –
Remove old
constructor
overload
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
TDD and Refactoring
public class SomeClass
{
private int _someParam;
public SomeClass(int someParam)
{
//...
_someParam = someParam;
}
public void Foo(int someParam)
{
//use someParam...
}
public void Foo()
{
//use _someParam...
}
}
Step3 – Add
new overload of
Foo
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
TDD and Refactoring
public class SomeClass
{
private int _someParam;
public SomeClass(int someParam)
{
//...
_someParam = someParam;
}
public void Foo()
{
//use _someParam...
}
}
Step4 (final) –
Remove old
overload of Foo
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
TDD and Legacy Code
©ArnonAxelrod,E4DSolutionsLtd.
TDD and Legacy Code
Legacy code TDD (loosely-coupled)
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Limits of TDD
• UI
• Multi-threading
• Integration with peripheral systems, including:
– Hardware (I/O)
– Operating System
– Database
– 3rd party applications and components
©ArnonAxelrod,E4DSolutionsLtd.
Quality
Testing
Unit Tests
TDD
ATDD
©ArnonAxelrod,E4DSolutionsLtd.
ATDD
ATDD
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
ATDD
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
ATDD
Stands for:
Accepance-Test Driven Development
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
ATDD
TDD is about writing the CODE RIGHT
ATDD is about writing the RIGHT CODE
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
ATDD
ATDD is about Communication
Mainly between Product, Dev and Test
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
ATDD is AKA:
• Agile Acceptance Testing
• Specification by Example
• Example Driven Development
• Executable Specifications
• ~= BDD (Behavior Driven Development)
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Problems with Waterfall
Specification
Photo by: Michal Marcol
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Problems with Agile Specification
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
How ATDD works?
Specification
by Examples
Scenarios
Acceptance
tests
©ArnonAxelrod,E4DSolutionsLtd.
Quality
Testing
Unit Tests
TDD
ATDD
©ArnonAxelrod,E4DSolutionsLtd.
FitNesse Demo
ATDD
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Benefits of ATDD for the Business
Analyst
• Developers will actually read the specifications that you write
• You will be sure that developers and testers understand the
specifications correctly
• You will be sure that they do not skip parts of the specification
• You can track development progress easily
• You can easily identify conflicts in business rules and
requirements caused by later change requests
• You’ll save time on acceptance and smoke testing
Source: Gojko Adzic – Bridging the Communication Gap
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Benefits of ATDD for the Developer
• Most functional gaps and inconsistencies in
the requirements and specifications will be
flushed out before the development starts
• You will be sure that business analysts actually
understand special cases that you want to
discuss with them
Source: Gojko Adzic – Bridging the Communication Gap
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Benefits of ATDD for the Developer
• You will have automated tests as targets to
help you focus the development.
• It will be easier to share, hand over and take
over code
• You’ll have a safety net for refactoring, making
your code cleaner [Arnon A.]
Source: Gojko Adzic – Bridging the Communication Gap
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Benefits of ATDD for the Tester
• You can influence the development process and
stop developers from making the same mistakes
over and over
• You will have a much better understanding of the
domain
• You’ll delegate a lot of dull work to developers,
who will collaborate with you on automating
the verifications
Source: Gojko Adzic – Bridging the Communication Gap
©ArnonAxelrod,E4DSolutionsLtd.©ArnonAxelrod,E4DSolutionsLtd.
Benefits of ATDD for the Tester
• You can build in quality from the start by raising concerns
about possible problems before the development starts
• You’ll be able to verify business rules with a touch of a button
• You will be able to build better relationships with developers
and business people and get their respect
• You’ll spend less time doing dull work, and more time
exploring “real” bugs and testing non-functional aspects (e.g.
performance, usability, etc). [Arnon A.]
Source: Gojko Adzic – Bridging the Communication Gap
©ArnonAxelrod,E4DSolutionsLtd.
Quality
Testing
Unit Tests
TDD
ATDD
©ArnonAxelrod,E4DSolutionsLtd.
Questions?
©ArnonAxelrod,E4DSolutionsLtd.
Quality
Testing
Unit Tests
TDD
ATDD
©ArnonAxelrod,E4DSolutionsLtd.
Thank you!

Unit Testing, TDD and ATDD

Editor's Notes

  • #5 תקנים דורשים Unit tests לקוחות לא מקבלים "יש באגים"
  • #6 המטרה של היום הזה: לענות על שאלות וחששות... תשאלו ותתשתתפו – זה בשבילכם!
  • #7 גם אני למדתי ככה
  • #8 להגדיל
  • #9 להזיז שמאלה את ה-happy customers לחשוב מחדש
  • #10 להעלות את הכותרות יותר למעלה
  • #11 קידוד עד הרגע האחרון! אין סטביליזיישן
  • #17 לשנות צבע של המילה ולמרכז
  • #29 A container for multiple unit tests
  • #32 שקף נפרד על Testing the test first
  • #33 שקף נפרד על Testing the test first
  • #34 שקף נפרד על Testing the test first
  • #36 * Refactoring זה בעיקר להוריד כפילויות
  • #37 להחליף תמונה TDD provides a safety net Caution: If tests are bad, refactoring can be more difficult than without! On the other hand, TDD drives for good tests Small steps, climbers rule
  • #38 להחליף תמונה TDD provides a safety net Caution: If tests are bad, refactoring can be more difficult than without! On the other hand, TDD drives for good tests Small steps, climbers rule
  • #39 להחליף תמונה TDD provides a safety net Caution: If tests are bad, refactoring can be more difficult than without! On the other hand, TDD drives for good tests Small steps, climbers rule
  • #40 להחליף תמונה TDD provides a safety net Caution: If tests are bad, refactoring can be more difficult than without! On the other hand, TDD drives for good tests Small steps, climbers rule
  • #41 להחליף תמונה TDD provides a safety net Caution: If tests are bad, refactoring can be more difficult than without! On the other hand, TDD drives for good tests Small steps, climbers rule
  • #42 להחליף תמונה TDD provides a safety net Caution: If tests are bad, refactoring can be more difficult than without! On the other hand, TDD drives for good tests Small steps, climbers rule
  • #43 להחליף תמונה TDD provides a safety net Caution: If tests are bad, refactoring can be more difficult than without! On the other hand, TDD drives for good tests Small steps, climbers rule
  • #44 להחליף תמונה TDD provides a safety net Caution: If tests are bad, refactoring can be more difficult than without! On the other hand, TDD drives for good tests Small steps, climbers rule
  • #46 אין טעם להוסיף טסטים לכל הקוד שכבר כתוב Detours (Moles) יכולים לעזור, וגם Pex
  • #63 להעביר ATDD לפני Clean code