BETTER SOFTWARE FASTER

DAVE FARLEY’S HOW TO GUIDE

Adopt GREAT Developer Habits

BEGINNERS GUIDE TO TDD (TEST DRIVEN DEVELOPMENT)
Introduction
NoneTEST
of us are born “great
DRIVEN programmers” - great programmers are regular programmers with great
DEVELOPMENT
habits! As with any acquired skill such as playing a musical instrument or studying a scientific discipline it
TDD is oneaofdesire
takes commitment, onlytoaexplore
few techniques
and creativity.that helpwayustotogetdesign
The best better
those things is tosoftware,
have fun! So
faster.
what are the great habits of a great software developer?
In order to create software that is easily “testable” we need software that
CodeweAscanCommunication
interact with and that allows us to capture the results of those
interactions
We might so ofthat
think of the target our we
codecan
as thematch
computerthem in the
- in reality assertions
though, in our tests.
it is other people!
• Focus on writing code that communicates well to other people, make it easy to read, understand and learn from.
“Testable”
Often code
this person will is more
be you, modular, more loosely-coupled, has better
in the future!
separation-of-concerns,
sepa
• Great programmers spend time and effort is inbetter
makingabstracted
their code clearand is more
and simple highly-it should
to understand,
cohesive.
communicate ideasThese areandalso
effectively the hallmarks of well-designed software.So
concisely
• TipsTDD helpsCode:
for Clearer to steer us towards better design.
◦ Pick clear descriptive names for modules, functions and variables. Pick names that allow you to make little
This is largely
sentences that makeas a result of TDD forcing us to apply Dependency Inversion
sense.
◦ so
Keepthat
eachwe canandinject
module functiontest-time components
small and focused with(Aim
on a single task. which we can
for functions capture,
of less than 5-10
lines) fake, those interactions that we want to test.
and
◦ Aim to write code that anyone could read so they can understand what's happening in their narrow focus in
just a few
TDD seconds.
is less about testing and more about good design.
Be RED
Cautious Of Frameworks
> GREEN > REFACTOR
Modern software frameworks can be helpful, but there are downsides - they also impose a structure to your code,
RED
This can mean your code might be forced to change when the framework does.
Start with
• A framework a failing
can impose test. structure on code that tends to lock you in, possibly preventing you
an external
migrating to a different one - use with care!
We always write the test BEFORE we write the code. See the test
• Maintain the freedom to change your code when you decide to. Think about the degree to which a framework
failitsbefore
forces moving
programming modelon to the
on you. next
Choose onesstep. Create
that ask a mini executable
less compromise from your code.
• Ask:specification.
how much of my code is tailored to reflect the framework specifics?
This is expressed as a specification of the
• Try to isolate any third-party code behind your own abstraction of its functions. This leaves you with greater
behavioural
choice if you wish to intent of the
change your mindcode, i.e what the code should do. So
in the future.

we start
“Askeach
not whattest withdo the
you can word
for your SHOULD.
framework, ask what your framework can do for you!”

Continuous
© Continuous Delivery
Delivery Ltd. 2023Ltd. 2020.
 BETTER SOFTWARE FASTER
DAVE FARLEY’S HOW TO GUIDE
Coding Is Design
BEGINNERS GUIDE TO TDD (TEST DRIVEN DEVELOPMENT)
Don’t get bogged down by tools and technology! Think instead about how your system really works? It is the
shapes of the solutions that really matter.
• Focus first and foremost on the information you are dealing with and how it is exchanged between different
TESTof your
parts DRIVEN
system. DEVELOPMENT
• Focus on managing the complexity of your system.
TDD iswithone
• Systems of only aarefew
low complexity techniques
systems that help us to design better software,
of good design!
faster.
• Good design in software is measured by how easy it is to change!.

In order
Managing to create software that is easily “testable” we need software that
Complexity!
welevel
At every canaiminteract with
for simplicity andand
preferthat allows
design choicesus
thatto capture the results of those
maximise:
• Modularity
interactions so that we can match them in the assertions in our tests.
• Cohesion
• Separation of Concerns
“Testable” code is more modular, more loosely-coupled, has better
• sepa
Abstraction
separation-of-concerns, is better abstracted and is more highly-
• Reduce Coupling
cohesive. These are also the hallmarks of well-designed software.So
TDD helps to steer us towards better design.
“Good design, not tool use, distinguishes the great developers from the not so great.”

This is largely as a result of TDD forcing us to apply Dependency Inversion

so that
Quality weFeatures
Over can inject test-time components with which we can capture,
and fake, those interactions that we want to test.
Great programmers take pride in the quality of the features they build. Focusing only on feature production ends up
TDD isandless
being slower, aboutfewer
producing testing
features,and
not more
more. about good design.
• Aim to retain and sustain your ability to make changes effectively and efficiently indefinitely.
• Adopt
RED incremental approaches like Continuous Delivery and Agile development.
> GREEN > REFACTOR
• Optimise for the long haul by building high quality now that will reduce rework in the future.
RED
Imagine yourself revisiting your code in the future - will it still make sense to you then? If not, refactor until it will.
Start with a failing test.
We always write the test BEFORE we write the code. See the test
fail before moving on to the next step. Create a mini executable
specification. This is expressed as a specification of the
behavioural intent of the code, i.e what the code should do. So
we start each test with the word SHOULD.

Continuous
© Continuous Delivery
Delivery Ltd. 2023Ltd. 2020.
 BETTER SOFTWARE FASTER
DAVE FARLEY’S HOW TO GUIDE
Social Activity
BEGINNERS GUIDE TO TDD (TEST DRIVEN DEVELOPMENT)
Great software developers talk to other people more often - and the best ones are great communicators.
• Remember - most effective software development is carried out in teams.
• Learn how to express your ideas - from simple to complex - clearly. If code is all about communication, and it
is, then improving your communication skills can only help!
TEST
• Pair DRIVENwillDEVELOPMENT
Programming improve your communication skills, as both pupil and teacher by forcing you to have
conversations
TDD is one about
ofcode
onlyandatofew
learntechniques
from others. that help us to design better software,
• If you are struggling with a solution or an idea, go and explain it to someone else. You’ll be amazed how often
faster.
you’ll solve the problem before you’ve even finished explaining it!
• Other
In ways to grow your communication skills: go out of your way to collaborate on unfamiliar tasks with people
order to create software that is easily “testable” we need software that
at work, write a blog, join a user/meetup group or online discussion forum.
we can interact with and that allows us to capture the results of those
interactions
Software so that
development does weincan
not thrive matchOf course
a vacuum! themthere
in the
will assertions in ouralone
be times when working tests.
allows you to
concentrate on a problem but don’t over do it, and always remember to share your ideas. Speaking of which…
“Testable” code is more modular, more loosely-coupled, has better
separation-of-concerns, is better abstracted and is more highly-
sepa
Avoidcohesive.
Code Ownership
These are also the hallmarks of well-designed software.So
Code isTDD helpsGreat
not yours! to developers
steer usare
towards
free with better
their ideasdesign.
and usually open to having them critiqued and
reviewed.
This isdefend
• Of course, largely as avigorously,
your ideas result ofbutTDD forcing
also always us toto changing
be open apply Dependency Inversion
your mind when you learn
so thatnew.
something we can inject test-time components with which we can capture,
and
• Don’t fake, those
be precious interactions
about “your” code - it’s notthat weit belongs
yours, want to test.
to the team!
• Be happy when you find code that you can delete!
TDD is less about testing and more about good design.
We want people to criticise our ideas to get new and different perspectives. While there may be one person who
knows a particular part of the system better, they should encourage, and support, others to change it.
RED > GREEN > REFACTOR
WorkREDIn Small Steps
Start
The best with a failing
programmers test. in small steps, checking each step as they go.
make progress
• UseWe
Testalways
Driven Development
write the- make
testaBEFORE
small change
wethen checkthe
write thatcode.
the testsSee
still pass!
the test
• Learn how to and get proficient at refactoring code, again make small changes and after each tiny step.
fail before moving on to the next step. Create a mini executable
Working in small steps is one
specification. Thisof the most important as
is expressed ideas
a inspecification
doing a better jobof
in software
the development. By doing so
we are optimising to get faster higher-quality feedback. By progressing in small steps, we learn more quickly,
behavioural
proceed intent are
with more confidence, of better
the code, i.e what
able to explore the code
our solutions, andshould
continuallydo. Sorefine and improve
judge,
them.
we start each test with the word SHOULD.

Continuous
© Continuous Delivery
Delivery Ltd. 2023Ltd. 2020.
 BETTER SOFTWARE FASTER
DAVE FARLEY’S HOW TO GUIDE

Conclusion
BEGINNERS GUIDE TO TDD (TEST DRIVEN DEVELOPMENT)
This may seem a lot to take in, and it may take a fair bit of effort to achieve… but everything worth pursuing in life
always does! Don’t fall for the narrative that someone is a “code guru” or “rockstar programmer”. The greatest
TEST DRIVEN
programmers are the onesDEVELOPMENT
who have written enough code to have made the most mistakes, and have learned from
them. Never be scared to make mistakes - learn, instead, to embrace them!
TDD is one of only a few techniques that help us to design better software,
“An expert is someone who knows some of the worst mistakes that can be made in his subject, and how to avoid them.”
faster. - Werner Heisenberg

In order to create software that is easily “testable” we need software that

Further Learning,
we can interactReading
with and &that
Viewing
allows us to capture the results of those
interactions so that we can match them in the assertions in our tests.
Books*:
“Testable”
• The Pragmatic code isyour
Programmer: more modular,
journey to mastery,more loosely-coupled,
20th Anniversary has better
Edition https://amzn.to/3EdXvBm
sepa
separation-of-concerns, is better abstracted and is more highly-
YouTubecohesive.
Videos: These are also the hallmarks of well-designed software.So
TDD helps to steer us towards better design.
• Don't Build Perfect Software https://youtu.be/NEJUkvWGuvw?si=FLzcGwaSzVILOhMf
• How This
To Avoid Big Upfront Design https://youtu.be/8GONv6jJsG0?si=nw8soud45512FiWf
is largely as a result of TDD forcing us to apply Dependency Inversion
• 5 Ways to Improve Your Code https://youtu.be/1KeJc6V4Jjk?si=eQS9rIT9awqdDlrt
so that we can inject test-time components with which we can capture,
• 5 Vital Tips For Junior Developers https://youtu.be/uN43mq_i4ko?si=MMbZp4_qXt0GcXQS
• How and
To Be Afake,
GREATthose interactions
Programmer that we want to test.
https://youtu.be/X99Be8wJBMI?si=wI7ybAGZcJ4j_sFk
• The Engineering Ep. 17 https://youtu.be/7FtNjeYKVAE?si=sic_AMX88n5MJGhu
TDD is less about testing and more about good design.
*We use Amazon Affiliate links for books. If you use these links to buy a book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
RED > GREEN > REFACTOR
RED
Start with a failing test.
We always write the test BEFORE we write the code. See the test
fail before moving on to the next step. Create a mini executable
specification. This is expressed as a specification of the
behavioural intent of the code, i.e what the code should do. So
we start each test with the word SHOULD.

Continuous
© Continuous Delivery
Delivery Ltd. 2023Ltd. 2020.