The document discusses unit testing, test-driven development (TDD), and acceptance test-driven development (ATDD). It begins with an introduction to the speaker and describes the importance and benefits of learning TDD. Various types of tests are defined, including unit tests, integration tests, and user interface tests. The basics of unit testing, including test structure and using doubles, are explained. TDD and how it works in an iterative cycle of writing a failing test, code, and refactoring is covered. ATDD is introduced as a way to write the right code through specification by examples and acceptance tests. The benefits of ATDD for different roles are outlined.

1. UNIT TESTING, TDD & ATDD
Arnon Axelrod, E4D Solutions

2. ©ArnonAxelrod,E4DSolutionsLtd.
ABOUT ME

3. ©ArnonAxelrod,E4DSolutionsLtd.
ABOUT YOU
 Position: Dev, Test, Product, Management, other?
 TDD/Unit testing experience

4. ©ArnonAxelrod,E4DSolutionsLtd.
WHY LEARN TDD TODAY?
Adoption (%
of martket)
time
Today
ATDD
TDD
Agile
Object-
Oriented

5. ©ArnonAxelrod,E4DSolutionsLtd.
Photo by: Stuart Miles
TDD?!

6. ©ArnonAxelrod,E4DSolutionsLtd.
Learning TDD is like learning to ride a bicycle

7. Quality Testing
Unit
Tests
TDD ATDD
QUALITY THROUGHOUT THE
PROJECT LIFECYCLE
What is quality?
Why it is important?
Quality

8. ©ArnonAxelrod,E4DSolutionsLtd.
QUALITY
No bugs
Stability
Testing
Design
Happy, Loyal customers
User eXperience
Clean code
Maintainability
Customer feedback

9. ©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

10. ©ArnonAxelrod,E4DSolutionsLtd.
THE PRODUCTIVITY MISCONCEPTION
Productivity
Features
Happy customers
MaintainabilityPressure
Legend:
Positive
relationship
Negative
relationship
Increased
Decreased
Stability
Clean code
Testing

11. Quality Testing
Unit
Tests
TDD ATDD
TESTING
Testing

12. ©ArnonAxelrod,E4DSolutionsLtd.
TYPES OF TESTS
Exploratory
Planned
Manual
Automated
White box Black box

13. ©ArnonAxelrod,E4DSolutionsLtd.
TYPES OF TESTS
UI
View Model
Client Logic
Server Proxy
Service Layer
Business Logic
DAL
ORM
DB
End-to-End

14. ©ArnonAxelrod,E4DSolutionsLtd.
TYPES OF TESTS
UI
View Model
Client Logic
Server Proxy
Service Layer
Business Logic
DAL
ORM
DB
Usability, UX

15. ©ArnonAxelrod,E4DSolutionsLtd.
TYPES OF TESTS
UI
View Model
Client Logic
Server Proxy
Service Layer
Business Logic
DAL
ORM
DB
Integration

16. ©ArnonAxelrod,E4DSolutionsLtd.
TYPES OF TESTS
UI
View Model
Client Logic
Server Proxy
Service Layer
Business Logic
DAL
ORM
DB
Functional
Mock
Mock
Mock

17. ©ArnonAxelrod,E4DSolutionsLtd.
TYPES OF TESTS
UI
View Model
Client Logic
Server Proxy
Service Layer
DAL
ORM
DB
Unit tests
Business Logic

18. ©ArnonAxelrod,E4DSolutionsLtd.
TYPES OF TESTS
Other:
 Performance
 Load (scalability)
 Install (deployment)
 Monkey testing

19. Quality Testing
Unit
Tests
TDD ATDD
UNIT TESTS BASICS
Unit
Testing

20. ©ArnonAxelrod,E4DSolutionsLtd.
WHAT’S A UNIT TEST?
 What’s a unit?
 Smallest testable functionality
 any testable functionality (BDD)
 Automatic
 Gray box

21. ©ArnonAxelrod,E4DSolutionsLtd.
BENEFITS OF UNIT TESTS
 Fast
 Easy to write and maintain
 Code coverage
 When fail, provide insight into the problem

22. ©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

23. ©ArnonAxelrod,E4DSolutionsLtd.
UNIT TESTS SHOULD:
 Read like a story
 Verify only one thing
 Have meaningful names
 Be fast!

24. ©ArnonAxelrod,E4DSolutionsLtd.
DOUBLES
(MOCKS)
Order class
+Items
+bool CheckAvailability (IInventory inventory)
+void Supply (IInventory inventory)
Inventory class
+int GetAvailablePieces (Item item)
+void Reduce(Item item, int count)
- DbConnectionProvider

25. ©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)
Inventory class (impl)
+int GetAvailablePieces (Item item)
+void Reduce(Item item, int count)
- DbConnectionProvider
InventoryDouble
+int GetAvailablePieces (Item item)
+void Reduce(Item item, int count)

26. ©ArnonAxelrod,E4DSolutionsLtd.
DOUBLES...
Double
Fake
Dummy
MockStub
Detour

27. ©ArnonAxelrod,E4DSolutionsLtd.
UNIT TEST STRUCTURE
Arrange Act Assert
Given When Then

28. ©ArnonAxelrod,E4DSolutionsLtd.
TEST SUITE
Suite Initialize
Test Initialize
Test Method 1
Test Cleanup
Suite Cleanup
Test Method 2 Test Method 3

29. Quality Testing
Unit
Tests
TDD ATDDTDD
TDD

30. ©ArnonAxelrod,E4DSolutionsLtd.
WHAT TDD IS ALL ABOUT?
Testing?!
Design!

31. ©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!

32. ©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

33. ©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

34. ©ArnonAxelrod,E4DSolutionsLtd.
THE WAY TDD WORKS:
Write a
failing
test
Write the
code to
make this
test pass
Refactor

35. ©ArnonAxelrod,E4DSolutionsLtd.
Write a
test
New
Test
Old
Tests
Write
production
code
All
Tests
Refactor
All
Tests

36. ©ArnonAxelrod,E4DSolutionsLtd.
TDD AND REFACTORING
Photo by: Chaiwat

37. ©ArnonAxelrod,E4DSolutionsLtd.
TDD AND REFACTORING
public class SomeClass
{
public SomeClass()
{
//...
}
public void Foo(int someParam)
{
// use someParam...
}
}
Initial state

38. ©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

39. ©ArnonAxelrod,E4DSolutionsLtd.
TDD AND REFACTORING
public class SomeClass
{
public SomeClass()
{
//...
}
public void Foo(int someParam)
{
// use someParam...
}
}
Initial state

40. ©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

41. ©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

42. ©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

43. ©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

44. ©ArnonAxelrod,E4DSolutionsLtd.
TDD AND LEGACY CODE

45. TDD AND LEGACY CODE
Legacy code TDD (loosely-coupled)

46. ©ArnonAxelrod,E4DSolutionsLtd.
LIMITS OF TDD
 UI
 Multi-threading
 Integration with peripheral systems, including:
 Hardware (I/O)
 Operating System
 Database
 3rd party applications and components

47. Quality Testing
Unit
Tests
TDD ATDD
ATDD
ATDD

48. ©ArnonAxelrod,E4DSolutionsLtd.
ATDD

49. ©ArnonAxelrod,E4DSolutionsLtd.
ATDD
Stands for:
Accepance-Test Driven Development

50. ©ArnonAxelrod,E4DSolutionsLtd.
ATDD
TDD is about writing the CODE RIGHT
ATDD is about writing the RIGHT CODE

51. ©ArnonAxelrod,E4DSolutionsLtd.
ATDD
ATDD is about Communication
Mainly between Product, Dev and Test

52. ©ArnonAxelrod,E4DSolutionsLtd.
ATDD IS AKA:
 Agile Acceptance Testing
 Specification by Example
 Example Driven Development
 Executable Specifications
 ~= BDD (Behavio Driven Development)

53. ©ArnonAxelrod,E4DSolutionsLtd.
PROBLEMS WITH WATERFALL SPECIFICATION
Photo by: Michal Marcol

54. ©ArnonAxelrod,E4DSolutionsLtd.
PROBLEMS WITH AGILE SPECIFICATION

55. ©ArnonAxelrod,E4DSolutionsLtd.
HOW ATDD WORKS?
Specification
by Examples
Scenarios
Acceptance
tests

56. Quality Testing
Unit
Tests
TDD ATDD
FITNESSE DEMO
ATDD

57. ©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

58. ©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
 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

59. ©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

60. ©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

61. Quality Testing
Unit
Tests
TDD ATDD
QUESTIONS?

62. Quality Testing
Unit
Tests
TDD ATDD
THANK YOU!