Introduction to TDD

Introduction to Test Driven
Development (TDD)
Ahmed MISBAH
06/02/2021

Agenda
1. A little about me
2. Introduction (Why?)
o Shift-left mindset
o Lean Thinking, Waste and Poke-Yoke
3. Test Driven Development (What and how?)
o What is TDD?
o How to do TDD?
o Deriving Test cases and Code Design
o Advantages of TDD
o Best Practices
4. Workshop – String Sum Kata
5. Advanced TDD
o Test Automation Pyramid
o Applying TDD in a multi-layer application

A little about me
• Software Architect
• Speaker at:
– Java Developer Conference
– Google Developer Group
– Africa and Middle East Conference
on Software Engineering
– DevOpsDays Cairo
– Orange DevTest Days

A little about me
• Degrees and Certifications:
– BSc. and MSc. Degree in Computer Science
– Sun Certified Enterprise Java Architect, Java
Developer, Mobile Developer, Web
Developer, Webservice Developer
– Oracle Certified Expert - JPA Developer
– Certified Scrum Master
– AWS Solution Architect - Associate
• Topics of interest:
– Agile and Lean
– DevOps
– Java
– Software Architecture
– Aviation
– Astronomy and space travel

Shift-left Mindset
“Most defects end up costing more than it would
have cost to prevent them. Defects are expensive
when they occur, both the direct costs of fixing
the defects and the indirect costs because of
damaged relationships, lost business, and lost
development time.”
Kent Beck, Extreme Programming Explained

Lean Thinking
Lean (SWD or Manufacturing) is a systematic method in
which the core idea is to maximize customer value while
minimizing waste
• Value is everything that your customer is willing to pay
money for
• Waste is any action or step in a process that does not
add value to the customer. In other words, waste is any
process that the customer does not want to pay for
• Muda ("non-value-adding work")
o Type 1: A non-value-added activity for an end customer but it is
necessary. It is targeted to minimize this type of wastage
o Type 2: A non-value-added activity for an end customer which is
not necessary. It is targeted to eliminate this type of wastage

Types of waste in Lean
Waste Type Production Software Development
Transport
Moving parts and materials
from one place to another
Task switching, interruptions,
handoffs
Inventory Undelivered products or parts
Undelivered code. Undelivered
features (i.e., partially done
work)
Motion
Unnecessary movement of the
worker
Unnecessary meetings, extra
effort to find information
Waiting Waiting Waiting (i.e., delays)
Overproduction Too many parts Features nobody uses
Over-processing
Spending a lot of time on a
given task
Unnecessary complex
algorithms solving simple
problems, manual tests (i.e.,
repeating the repeated)
Defects Broken parts Bugs

Poke-Yoke
• It’s a quality assurance process introduced by Japanese
engineer Shigeo Shingo. This term is used in the Japanese
language as “Poka” meaning mistake and “Yoke” meaning
prevent i.e., mistake preventing or mistake-proofing
technique.
• The purpose of Poka-Yoke is to develop processes to reduce
defects by avoiding or correcting (design to show alerts or
warning messages to the user) mistakes in early design and
development phases. This technique is mostly used in
manufacturing industries but now this effective technique
is also adapted to software development processes as well.

Defect Detection vs. Prevention
• Test-devices were designed to inexpensively check if a
product was defective. Poka-yoke tests were inexpensive,
repeatable and reliable. They could be given to workers on
the manufacturing line, to check a product straight after
they make it.
• Checking at the source, rather than on the end, was one of
the most important ideas described by Shigeo Shingo in his
book on Zero Quality Control. Mary Poppendieck often
comments on those ideas that ‘inspection to find defects is
waste, inspection to prevent defects is essential’. That is
basically what test-driven development is all about.

To sum up….
Shift-left mindset and Poke-Yoke promote the idea
of testing early to:
1. Prevent defects rather than inspect for defects
2. Reduce the cost of fixing defects
3. Build your product to meet quality standards and
functional requirements (i.e., mistake-proof design)
And here comes TDD!

What is TDD?
• Test-Driven Development (TDD) is a software
development process relying on software
requirements being converted to test
cases before software is fully developed
• This is opposed to software being developed
first and test cases created and executed later
• Kent Beck is credited with having developed
or 'rediscovered’ the technique

The three laws of TDD
• First Law: You may not write production code
until you have written a failing unit test.
• Second Law: You may not write more of a unit
test than is sufficient to fail, and not compiling
is failing.
• Third Law: You may not write more
production code than is sufficient to pass the
currently failing test.

TDD and eXtreme Programming
• Testing in XP:
– All code must have unit tests
– All code must pass all unit tests before it can be
released.
– When a bug is found tests are created before the
bug is addressed (a bug is not an error in logic, it is
a test that was not written)
– Acceptance tests are run often, and the results are
published

What is a Test Case?
A test case is a specification of the inputs,
execution conditions, testing procedure, and
expected results that define a single test to be
executed

Test Case ID Test Case
Description
Prerequisites Test Steps Test Data Expected Results Actual Results Pass/Fail
TC01 Check
Customer
Login with
valid Data
Customer data
exists in the
DB
1. Go to
site
2. Enter
UserId
3. Enter
Passwor
d
4. Click
Submit
• Email
address =
ahmed
• Password =
1234
User should login
to the application
As expected Pass

How do we derive Test Cases?
Test Design Techniques
Black-box Techniques
• Boundary Value Analysis
• Equivalence Partitioning
• Decision Tables
• State Transition
• Pairwise Testing
• Use case Testing

Code Design
• TDD can also stand for Test Driven Design
• Use the Russian design philosophy
“Nakayanki”, that translates as "working with
a piece of paper on your knee"

Advantges of TDD
1. Better software design and higher code quality
2. Detailed code documentation
3. Code flexibility and easier maintenance
4. You get a reliable solution
5. More courage!
6. Continous testing to find injected bugs
7. Time required for project development is
reduced
8. Save project costs in the long run

Test Structure
1) Setup: Put the Unit Under Test (UUT) or the overall test
system (SUT) in the state needed to run the test.
2) Execution: Trigger/drive the UUT to perform the target
behavior and capture all output, such as return values and
output parameters.
3) Validation/Verification: Ensure the results of the test are
correct. These results may include explicit outputs
captured during execution or state changes in the UUT.
This step is also known as Assertion in some test
frameworks.
4) Cleanup: Restore the UUT or the SUT to the pre-test state.
This restoration permits another test to execute
immediately after this one. In some cases, in order to
preserve the information for possible test failure analysis
the cleanup should be starting the test just before the
test's setup run

F.I.R.S.T Rules
• Fast Tests should be fast. They should run quickly. When tests run
slow, you won’t want to run them frequently. If you don’t run them
frequently, you won’t find problems early enough to fix them easily.
You won’t feel as free to clean up the code. Eventually the code will
begin to rot.
• Independent Tests should not depend on each other. One test
should not set up the conditions for the next test. You should be
able to run each test independently and run the tests in any order
you like. When tests depend on each other, then the first one to fail
causes a cascade of downstream failures, making diagnosis difficult
and hiding downstream defects.
• Repeatable Tests should be repeatable in any environment. You
should be able to run the tests in the production environment, in
the QA environment, and on your laptop while riding home on the
train without a network. If your tests aren’t repeatable in any
environment, then you’ll always have an excuse for why they fail.
You’ll also find yourself unable to run the tests when the
environment isn’t available.

F.I.R.S.T Rules
• Self-Validating The tests should have a boolean output.
Either they pass or fail. You should not have to read
through a log file to tell whether the tests pass. You should
not have to manually compare two different text files to
see whether the tests pass. If the tests aren’t self-
validating, then failure can become subjective and running
the tests can require a long manual evaluation.
• Timely The tests need to be written in a timely fashion.
Unit tests should be written just before the production
code that makes them pass. If you write tests after the
production code, then you may find the production code to
be hard to test. You may decide that some production code
is too hard to test. You may not design the production code
to be testable.

Use GWT notation
The Given-When-Then formula is a template intended to guide the
writing of acceptance tests for a User Story:
• Given - Describes the preconditions and initial state before the start
of a test and allows for any pre-test setup that may occur
• When - Describes actions taken by a user during a test
• Then - Describes the outcome resulting from actions taken in the
When clause
An example:
• Given my bank account is in credit, and I made no withdrawals
recently,
• When I attempt to withdraw an amount less than my card’s limit,
• Then the withdrawal should complete without errors or warnings

Other best practices
1. Don’t treat test code as a second-class citizen
2. One assertion per test (disputable)
3. Single Concept per Test
4. Fake it till you make it (using mocks, stubs,
simulators, spies and dummies)

String Sum - User Story
As a user
I want to add two real numbers in string format
So that I would see their sum
Acceptance Criteria:
• A real number is any number >=0
• A real number is a number with no decimals
• My method should take two strings as an input and return a
long value as output
• My method should throw an error in case a non real number
is provided

String Sum – Test Design
Black-box test techniques that can be used:
o Boundary Value Analysis
o Equivalence Partitioning
o Decision Tables

String Sum – Decision Table
Rules String a String b Output
Add two strings that
are real numbers
10 150 160
are real numbers at
their boundaries
0
9,223,372,036,854,775
,807
9,223,372,036,854,775
,807
are real numbers that
start with zero
015 015 30
Add two strings with
one number that is
negative
-1 5 Error
one number that has a
decimal
0.5 15 Error
one value as
characters
aaaaa 55 Error

Spring Boot Application Structure
Spring Boot Application
Spring MVC - Controller
Spring Bean - Service
Spring Data - Repository
JPA/Hibernate - ORM
Utilities
Some Data store or
queue
An External API

Unit Tests
JPA/Hibernate - ORM
Utilities (Mock)
Unit tests Service (Mock)
Data Store (Stub)
Unit tests
Unit tests
Repository (Mock)

Unit Tests
• Unit tests will run in CI server
• Tests will be part of the Spring Boot application
• jUnit 5 or TestNG can be used
• Mockito can be used for mocking
• Controller tests will use @WebMvcTest annotation:
https://reflectoring.io/spring-boot-web-controller-test/
• Repository tests will use @DataTestJPA annotation, which
implicitly used H2 and tests ORM as well:
https://reflectoring.io/spring-boot-data-jpa-test/
• Liquibase will be used to create schemas at the start of
each test class
• Sprint @Sql annotation will be used to remove and insert
data before each test case:
https://www.javarticles.com/2016/02/spring-sql-annotation-
example.html

Component Tests
JPA/Hibernate - ORM
Utilities
Component tests
Data Store (Stub)
Web server (Stub)

Component Tests
• Component tests will run in CI server
• Tests will be part of the Spring Boot
application
• jUnit 5 or TestNG can be used
• Tests will use @SpringBootTest annotation
• REST/SOAP APIs will be stubbed using
WireMock, Mock Server or Postman:
https://www.baeldung.com/introduction-to-
wiremock

Component Tests
• MySQL will be stubbed using H2
• Liquibase will be used to create schemas at
the start of each test class
• Sprint @Sql annotation will be used to remove
and insert data before each test case:
https://www.javarticles.com/2016/02/spring-
sql-annotation-example.html

Thank You!
https://twitter.com/AhmedMisbahTech https://www.linkedin.com/in/ahmed-misbah-msc-251a3a32/ https://www.youtube.com/channel/UCZxEBqvA1fGKLusLwoadf_w

Introduction to TDD

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Introduction to TDD

Similar to Introduction to TDD (20)

More from Ahmed Misbah

More from Ahmed Misbah (19)

Recently uploaded

Recently uploaded (20)

Introduction to TDD