Test Driven Development (TDD)

(Unit testing and Refactoring)

 What it is Test-Driven Development (TDD) 1?
• Test Driven Development (TDD) is a ”Test-First” approach or method
of creating software which means we are writing tests before writing
code
• Uncle Bob describes TDD with three rules, but a refactored (clearer
and shorter) version is

Write only enough of a unit test to fail

Write only enough production code to make the failing unit test pass
• It may seem unintuitive to write tests for code that doesn't exist yet,
but by writing tests first, we ensure we have a clear expectation of
what the code will do
• Watch: How TDD is related to the quality of code

https://www.youtube.com/watch?v=is41fgDrqn0
What it is Test-Driven Development (TDD) 2?
• Over the years TDD has proved itself as one of the best techniques for
increasing the software quality
• This way of development is reducing the number of bugs in your code and
gives you the ability to reduce or even eliminate manual testing
• Having a bug in production can be very expensive. Certain statistics say that
finding a bug during development is 10 times cheaper than finding the same
bug during QA (Quality Assurance ) and 100 times cheaper than finding it in
production

Source: https://en.wikipedia.org/wiki/Software_testing
 What it is Test-Driven Development (TDD) 3?
• TDD comes from the eXtreme Programming (XP) world and have a
widespread adoption. In its essence, it is consisting of small cycles of
development
• Every cycle have three steps (the TDD mantra), Red – Green – Refactor
1.During the Red phase, we write a unit test for functionality
that doesn’t yet exist and that will fail
2.Green phase refers to the moment we implement the
minimum amount of code functionality to pass that test
3.And finally we refactor our code

Then we repeat the whole process for next
functionality

One of the cool things with TDD is that this
way refactoring has a safety net, and we can
do it stress-free!
Benefits of Test-Driven Development (TDD) 1
• In general, by using Test Driven Development we avoid creating
overcomplicated designs and overengineered systems. This is one of the
biggest benefit of TDD. Thats why people also refers to this approach as
Test Driven Design
• It forces the developer to design classes properly and to follow principles like

KISS – keep it simple, stupid

https://en.wikipedia.org/wiki/KISS_principle

YAGNI – You aren't gonna need it

https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

DRY – Don't repeat yourself

https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

SOLID

https://en.wikipedia.org/wiki/SOLID
 SOLID
• Single responsibility principle (split responsibility among classes)

A class should have only a single responsibility, that is, only changes to one part of
the software's specification should be able to affect the specification of the class.
• Open – closed principle (class modifyers, inheritance, interfaces)

"Software entities ... should be open for extension, but closed for modification."
• Liskov substitution principle (inheritance, polymorphism)

"Objects in a program should be replaceable with instances of their subtypes
without altering the correctness of that program."
• Interface segregation principle

"Many client-specific interfaces are better than one general-purpose interface."
• Dependency inversion principle (DI, IoC, loose coupling, interfaces)

One should "depend upon abstractions, [not] concrete instances."

DependencyInjection: DepInjDemo
Benefits of Test-Driven Development (TDD) 2
• Before writing code, writing unit tests forces you to detail your requirements in a
useful fashion.
• While writing code, unit tests keep you from over-coding. When all the test cases
pass, the function is complete.
• When refactoring code, they can help prove that the new version behaves the same
way as the old version.
• When maintaining code, having tests will help you cover your ass when someone
comes screaming that your latest change broke their old code. (“But sir, all the unit
tests passed when I checked it in...”)
• When writing code in a team, having a comprehensive test suite dramatically
decreases the chances that your code will break someone else’s code, because you
can run their unit tests first

As a team breaks up the assignment, everybody takes the specs for their task, writes unit
tests for it, then shares their unit tests with the rest of the team. That way, nobody goes off too
far into developing code that doesn’t play well with others
 Refactor phase 1
• In the refactor phase, you are allowed to change the code, while keeping all
tests green, so that it becomes better. Whats “better” means is up to you!

But there is something mandatory: you have to remove code duplication! Kent
Beck suggests in his book ”Test Driven Development: By Example” that removing
code duplication is all you need to do
• In this phase you play the part of a picky programmer who wants to
fix/refactor the code to bring it to a professional level. In the green phase,
you’re showing off your skills to your users. But in the refactor phase, you’re
showing off your skills to the programmers who will read your
implementation
• Removing code duplication often results in abstraction.
A typical example is when you move two pieces of similar
code into a helper class that works for both the
functions/classes where the code has been removed
 Refactor phase 2
• Left code example below could be refactored into right hand side code
• Just keep in mind that you cannot move to another test unless you have
removed all the code duplication
public class Hello {
public PromiseHelper Greet() {
return PromiseHelper.Timeout(100).then(() => 'hello');
public class Promise { }
public Promise(/* code */) { }
/* code */
} public class Random {
} public PromiseHelper Toss() {
return PromiseHelper.Timeout(200).then(() => Math.Random());
public class Hello { }
public Promise Greet() { }
return new Promise(setTimeout('Hello', 100));
} public class PromiseHelper {
} static Promise Timeout(int delay) {
return new Promise(setTimeout(delay));
public class Random { }
public Promise Toss() { }
return new Promise(setTimeout(Math.Random(), 200));
} const var logResult = result => console.log(result);
} new Hello().Greet().then(logResult);
new Random().Toss().then(logResult);
new Hello().Greet().then(result => console.log(result));
new Random().Toss().then(result => console.log(result));
 TDD code example 1
• User stories we need to implement (steps in 1.1-1.2, 2.1-2.2, ... )

A user is able to assign Parents and Kids to a house number

A user is able to add residents to the House

A user is able to turn Parents with assigned Kids to pickles
• User story → Test scenario → Test case
import unittest import pickle
from family import Parent, Kid, House test_family.py # 1.2
family.py
# 1.1 class Parent(object):
class ParentTests(unittest.TestCase): def __init__(self, loc):
def test_location_returns_equal(self):
self.location = loc
parent = Parent(68)
self.assertEqual(parent.location, 68)
# 2.1 # 2.2
class KidTests(unittest.TestCase): class Kid(object):
def test_location_returns_equal(self): def __init__(self, loc):
kid = Kid(68) self.location = loc
self.assertEqual(kid.location, 68)
# 3.1 # 3.2
class HouseTests(unittest.TestCase): class House(object):
def test_get_all_residents_returns_count_equal(self): def __init__(self):
house = House()
self.__residents__ = [] # private member
residents = house.get_all_residents()
self.assertCountEqual(residents, [])
if __name__ == '__main__': def get_all_residents(self):
unittest.main(argv=['first-arg-is-ignored'], exit=False) return self.__residents__
 TDD code example 2
test_family.py family.py
class HouseTests(unittest.TestCase): class House(object):
# 4.1 # 4.2
def test_add_resident_returns_equal(self): def add_resident(self, resident):
house = House() self.__residents__.append(resident)
mum = Parent(68)
kid1 = Kid(68)
house.add_resident(mum)
class Kid(object):
house.add_resident(kid1) def __init__(self, loc):
residents = house.get_all_residents() # 5.2
self.assertEqual(residents[0], mum) self.is_assigned = False
self.assertEqual(residents[1], kid1)
class KidTests(unittest.TestCase): class Parent(object):
# 5.1 def __init__(self, loc):
def test_is_assigned_returns_false(self): # 6.2
kid = Kid(68) self.kid = None
self.assertFalse(kid.is_assigned)
# 7.2
class ParentTests(unittest.TestCase):
# 6.1
def assign(self, kid):
def test_has_kid_returns_equal(self): self.kid = kid
parent = Parent(68) kid.is_assigned = True
self.assertEqual(parent.kid, None)
# 7.1 # step 8, 9 and 10 in the python files
def test_assign_kid_returns_equal(self):
parent = Parent(68)
kid = Kid(68)
https://rubikscode.net/
parent.assign(kid) 2019/03/04/test-driven-
self.assertEqual(parent.kid, kid)
self.assertTrue(kid.is_assigned) development-tdd-with-python/
Behavior Driven Development (BDD)
• The two main practices of BDD are

Specification by Example (SbE) and Test Driven Development (TDD)
• BDD focuses on

Providing a shared process and shared tools promoting communication to the
software developers, business analysts and stakeholders to collaborate on
software development, with the aim of delivering product with business value

What a system should do and not on how it should be implemented

Providing better readability and visibility

Verifying not only the working of the software but also that it meets the customer’s
expectations
• Specification by Example (SbE)

SbE uses examples in conversations to illustrate the business rules and the
behavior of the software to be built and thereby enables the product owners,
business analysts, testers and the developers to eliminate common
misunderstandings about the business requirements
Recommended TDD viewing and reading 1
• Test Driven Development: what it is, and what it is not

https://medium.freecodecamp.org/test-driven-development-what-it-is-and-what-it-is-not-
41fa6bca02a2
• Getting Started with Test Driven Development

https://dev.to/chasestevens/getting-started-with-test-driven-development-1o8f
• BDD, TDD and ATTD

https://www.tutorialspoint.com/behavior_driven_development/
behavior_driven_development_quick_guide.htm
• Introduction to Test Driven Development (TDD)

https://medium.com/@ssaurel/introduction-to-test-driven-development-tdd-61a13bc92d92

http://www.agiledata.org/essays/tdd.html
• Test Driven Development (TDD) with Python

https://rubikscode.net/2019/03/04/test-driven-development-tdd-with-python/
• 1) How TDD is related to the quality of code, 2) Uncle Bob on TDD, 3) The Three Laws of TDD
(Featuring Kotlin)
1) https://www.youtube.com/watch?v=is41fgDrqn0
2) https://www.youtube.com/watch?v=GvAzrC6-spQ
3) https://www.youtube.com/watch?v=qkblc5WRn-U
Recommended TDD viewing and reading 2
• Self studies
• How to work with Test Driven development in Python:
an implementation of Rövarspråket

http://www.pererikstrandberg.se/blog/index.cgi?
page=PythonUnitTest
• Rövarspråket in CSharp

http://www.pererikstrandberg.se/blog/index.cgi?
page=CsharpUnitTestInSharpDevelop
• Per Erik Strandberg blog about Test

http://www.pererikstrandberg.se/blog/index.cgi?
page=KategoriTest
• All code above updated

OneDrive > gmi2j3 > lectures > code_rovarsprak