The document discusses the importance of software design and unit testing in ensuring software quality, emphasizing the need for clean code and the economic benefits of good design. It introduces Test Driven Development (TDD) as a best practice that drives design and aids in delivering functionality efficiently. Key concepts include managing technical debt and recognizing code smells to improve maintainability and robustness of the software.

1. SOFTWARE QUALITY
VIA UNIT TESTING
Shaun Abram
April 20, 2013
Email: Shaun@Abram.com Blog: shaunabram.com
Twitter: @shaunabram LinkedIn: linkedin.com/in/sabram
These slides available at shaunabram.com/dcc13

2. 2
Software Quality via Unit Testing
The value of software design
Automated testing
Clean code
Goal:
Deliver value to our users

3. 3
Software Quality via Unit Testing
The value of software design

4. 4
Why should we care about „good‟ design in software?
We need less focus on quality so we can
add more features
Do we really need unit tests?
Refactoring doesn‟t change what the code
does, so why bother?
How do you respond?

5. 5
Why should we care about „good‟ design in software?
Take the moral high ground?

6. 6
Why should we care about „good‟ design in software?
We need to have economic reasons
Remember: Our goal is to deliver value to our users

7. 7
What is Quality in software anyway?
Intuitive GUI
Few defects
Modular Design

8. 8
What is Quality in software anyway?
Intuitive GUI
Few defects Visible to user
Modular Design Transparent to user

9. 9
Fowler‟s Design Stamina Hypothesis

10. 10
Technical debt
The eventual consequences of poor design in a codebase

11. 11
Technical debt
The eventual consequences of poor design in a codebase
Interest payments can come in the form of:
1. Bugs
2. Just understanding what the heck the current code does
3. Refactoring
4. Completing unfinished work

12. 12
Technical debt
Pay down?
Accept?
But, don‟t build bad on top of bad…

13. Design Stamina
Design
stamina to
continually and consistently deliver functionality
faster and with less bugs to our users
Business value to our clients

14. 14
Clean code that works
• The value of software design
• Automated testing

15. 15
Unit testing
A unit test is a piece of code that executes a specific
functionality („unit‟) in the code, and
• Confirms the behavior or result is as expected.
• Determines if code is „fit for use‟
Example…

16. 1

17. •
1

18. 1

19. 1

21. 2

22. 2

23. 2

24. 2

25. 25
What unit tests provide
Unit tests don‟t necessarily help find bugs.
Instead, unit tests:
• Drive design

26. 26
What unit tests provide
Unit tests don‟t necessarily help find bugs.
Instead, unit tests:
• Drive design
• The tests act as the first user of the code, making you think about:
• What should this code do
• Border conditions (0, null, -ve, too big)
• Force you to use good design:
• Short, focused methods
• Dependency Injection
• Writing a class is different from using a class!

27. 27
What unit tests provide
Unit tests don‟t necessarily help find bugs.
Instead, unit tests:
• Drive design
• Act as safety buffers by finding regression bugs
• Provide documentation

28. 28
What unit tests provide
Unit tests don‟t necessarily help find bugs.
Instead, unit tests:
• Drive design
• Act as safety buffers by finding regression bugs
• Provide documentation
Can also be used on legacy codebases

29. 29
Unit testing limitations
1. Can not prove the absence of bugs
2. Lot‟s of code (x3-5)
3. Some things difficult to test

30. 30
So should we unit test?
Not only should we unit test,
We should let unit tests drive development and design…
Test Driven Development (TDD)

31. 31
Test Driven Development (TDD)

32. 32
Test Driven Development (TDD)

33. 33
Test Driven Development (TDD)

34. 34
Test Driven Development (TDD)
Red - Green – Refactor: the TDD Mantra
No new functionality without a failing test
No refactoring without passing tests

35. 35
Test Driven Development (TDD) Example
Write a simple StringCalculator class with a method
Integer add(String numbers)
A String of comma separated numbers should return their
sum e.g. “1,2,10” should return 13.
A single number String should return that number e.g. “3”
should return 3
An empty String should return 0
For brevity, our test will focus on valid inputs.

36. 36
Test Driven Development (TDD) Example
Write a simple StringCalculator class with a method
Integer add(String numbers)
Code demo…

37. 3

43. Refactor?

48. Refactor?

57. These tests act like the original
developer looking over your
shoulder and advising you, long
after that developer has left…

58. 58
Test Driven Development (TDD)
Red - Green – Refactor: the TDD Mantra
No new functionality without a failing test
No refactoring without passing tests

59. 59
Clean code that works
• The value of software design
• Automated testing

60. 60
Clean code that works
• The value of software design
• Automated testing
• Clean code

61. 61
• Feedback…
• XKCD

62. 6

63. 63
Code Smells
What are code smells?
“Certain structures in code suggest (sometimes they scream for) the
possibility of refactoring.”
Martin Fowler. Refactoring: Improving the design of existing code

64. 64
Code Smells
• Duplicated code
• Long switch/if statements
• Long methods
Even one line methods can be OK:
if ( (account != null) && ( (account.getBalance() > 0) || (!account.overdraftLimitReached()) ) {
…
}
if (account.hasFundsAvailable()) {
…
}

65. 65
Code Smells
• Duplicated code
• Long switch/if statements
• Long methods
• Poor method names
int process(int id) { //bad!
int calculateAccountBalance(int accountID) { //better

66. 66
Code Smells
• Duplicated code
• Long switch/if statements
• Long methods
• Poor method names
• In-line comments
• Large classes
• Symptoms
• Too many methods (>10 public?)
• Too many instance variables – is every instance variable used in every
method?
• Solutions
• Eliminate redundancy / duplicated code
• Extract new/sub classes

67. 67
Clear Code
Make the intent of your code clear
Code should be clear, concise and easy to understand
How many times will the code you are about to write be read?
Studies show poor readability correlates strongly with defect
density1
Avoid attrition & complete re-writes
1"Learning a Metric for Code Readability," IEEE Transactions on Software Engineering, 09 Nov.
2009. IEEE computer Society Digital Library. IEEE Computer Society

68. 68
Summary
• Good design gives us the stamina to continually and
consistently deliver business value
• Unit tests are an integral part of good design; TDD is even
better
• Good design can also simply be cleaner code;
Aggressively refactor to achieve this!
Final thought:
Every time you are in a piece of code,
just make one small improvement!

69. 69
Recommended Reading
Test Driven Development Growing Object-Oriented
Kent Beck
Software, Guided by Tests
Freeman & Pryce
Refactoring: Improving the Design Effective Unit Testing
of Existing Code Lasse Koskela
Martin Fowler, Kent Beck et. al.

70. Questions?
All slides available at: shaunabram.com/dcc13
Email: Shaun@Abram.com Blog: shaunabram.com
Twitter: @shaunabram LinkedIn: linkedin.com/in/sabram
7