Why Clean Code

Code is clean if it can be understood easily by everyone on the team. With

understandability comes readability, changeability, extensibility and
maintainability. All the things needed to keep a project going over a long
time without accumulating up a large amount of technical debt.

high

Viscosity of Design

Responsiveness

high
Cost of Change (CoC)

Viscosity of Environment

Needless Repetition

Writing clean code from the start in a project is an investment in keeping

the cost of change as constant as possible throughout the lifecycle of a
software product. Therefore, the initial cost of change is a bit higher when
writing clean code (grey line) than quick and dirty programming (black line),
but is paid back quite soon. Especially if you keep in mind that most of the
cost has to be paid during maintenance of the software. Unclean code
results in technical debt that increases over time if not refactored into clean
code. There are other reasons leading to Technical Debt such as bad
processes and lack of documentation, but unclean code is a major driver. As
a result, your ability to respond to changes is reduced (red line).

In Clean Code, Bugs Cannot Hide

Liskov Substitution Principle (LSP)

+

We normally build software by adding, extending or changing features.

However, removing elements is important so that the overall design can be
kept as simple as possible. When a block gets too complicated, it has to be
removed and replaced with one or more simpler blocks.

Multiple Languages in One Source File

Environment
Project Build Requires Only One Step

Source Control System

Continuous Integration
Overridden Safeties
Dependency Injection
Decouple Construction from Runtime

Micro Layers
Dependencies
Make Logical Dependencies Physical
Singletons / Service Locator
Base Classes Depending On Their Derivatives
Too Much Information
Feature Envy

Classes that change together are packaged together.

Artificial Coupling
Hidden Temporal Coupling

When you make a decision in your code, make sure you make it precisely.
Know why you have made it and how you will deal with any exceptions.

The dependency graph of packages must have no cycles.

Something put in the wrong place.

Aka Law of Demeter, writing shy code.

A module should know only its direct dependencies.

Names have to reflect what a variable, field, property stands for. Names
have to be precise.

Choose Names at Appropriate Level of Abstraction

Name Interfaces After Functionality They Abstract
Name Classes After How They Implement Interfaces

+
+
+

The name of a class should reflect how it fulfils the functionality provided by
its interface(s), such as MemoryStream : IStream

Name Methods After What They Do

The name of a method should describe what is done, not how it is done.

Use Long Names for Long Scopes

fields parameters locals loop variables

long
short

Names Describe Side Effects

+

Do not mix code that handles multi-threading aspects with the rest of the
code. Separate them into different classes.

Misplaced Responsibility

If, for example, the order of some method calls is important, then make
sure that they cannot be called in the wrong order.

The name of an interface should be derived from its usage by the client.

ONE SWITCH: There may be no more than one switch statement for a
given type of selection. The cases in that switch statement must create
polymorphic objects that take the place of other such switch statements in
the rest of the system.

Separate Multi-Threading Code

Choose names that reflect the level of abstraction of the class or method
you are working in.

Favour symmetric designs (e.g. Load Save) and designs that follow
analogies (e.g. same design as found in .NET framework).

Classes that are used together are packaged together.

Things that dont depend upon each other should not be artificially coupled.

Have a reason for the way you structure your code, and make sure that
reason is communicated by the structure of the code. If a structure appears
arbitrary, others will feel empowered to change it.

Symmetry / Analogy

The methods of a class should be interested in the variables and functions

of the class they belong to, and not the variables and functions of other
classes. Using accessors and mutators of some other object to manipulate
its data, is envying the scope of the other object.

Naming
Choose Descriptive / Unambiguous Names

Minimise interface to minimise coupling

Dont Be Arbitrary

The granule of reuse is the granule of release.

Base classes should work with any derived class.

Transitive Navigation

Prefer Polymorphism To If/Else or Switch/Case

Use dependency injection. Singletons hide dependencies.

If you have a constant such as default or configuration value that is known

and expected at a high level of abstraction, do not bury it in a low-level
function. Expose it as an argument to the low-level function called from the
high-level function.

If one module depends upon another, that dependency should be physical,

not just logical. Dont make assumptions.

Do not add functionality on top, but simplify overall.

Design
Keep Configurable Data at High Levels

Prevent configuration just for the sake of it or because nobody can decide
how it should be. Otherwise, this will result in overly complex, unstable
systems.

Enforce design decisions with structure over convention. Naming

conventions are good, but they are inferior to structures that force
compliance.

Depend in the direction of stability.

Do not override warnings, errors, exception handling they will catch you.

Structure over Convention

Stable Dependencies Principle (SDP)

Assure integrity with Continuous Integration

Classes should either do stuff (algorithm, read data, write data, ) or

orchestrate other classes. This reduces coupling and simplifies testing.

Package Coupling
Acyclic Dependencies Principle (ADP)

Always use a source control system.

Do stuff or know others, but not both

Common Reuse Principle (CRP)

Run all unit tests with a single command.

Be Precise

Common Closure Principle (CCP)

C#, Java, JavaScript, XML, HTML, XAML, English, German

Smaller classes are easier to grasp. Classes should be smaller than about
100 lines of code. Otherwise, it is hard to spot how the class does its job and
it probably does more than a single job.

Package Cohesion
Release Reuse Equivalency Principle (RREP)

Over Configurability
+

Leave the campground cleaner than you found it.

Root Cause Analysis

Fields holding data that does not belong to the state of the instance but are
used to hold temporary data. Use local variables or extract to a class
abstracting the performed action.

Decoupling the construction phase completely from the runtime helps to

simplify the runtime behaviour.

Make fine grained interfaces that are client-specific.

Classes Should be Small

Simpler is always better. Reduce complexity as much as possible.

Fields Not Defining State

Depend on abstractions, not on concretions.

Interface Segregation Principle (ISP)

When a software system has to be maintained, extended and changed for a

long time, keeping change local reduces involved costs and risks. Keeping
change local means that there are boundaries in the design which changes
do not cross.

Break your system down into components that are of a size you can grasp
within your mind so that you can predict consequences of changes easily
(dependencies, control flow, ).

Dependency Inversion Principle (DIP)

Keep it Simple, Stupid (KISS)

Executing Tests Requires Only One Step

Derived classes must be substitutable for their base classes.

Cohesion is the degree to which elements of a whole belong together.

Methods and fields in a single class and classes of a component should have
high cohesion. High cohesion in classes and components results in simpler,
more easily understandable code structure and design.

Mind-sized Components

Class Design
Single Responsibility Principle (SRP)

Coding-, architecture-, design guidelines (check them with tools)

Check out and then build with a single command.

You should be able to extend a classes behaviour without modifying it.

A component that is only loosely coupled to its environment can be more

easily changed or replaced than a strongly coupled component.

It is Easy to Remove

The code is hard to understand. Therefore, any change takes additional time
to first reengineer the code and is more likely to result in defects due to not
understanding the side effects.

Open Closed Principle (OCP)

Two classes, components or modules are coupled when at least one of

them uses the other. The less these items know about each other, the
looser they are coupled.

Change is Local

Code contains exact code duplications or design duplicates (doing the same
thing in a different way). Making a change to a duplicated piece of code is
more expensive and more error-prone because the change has to be made
in several places with the risk that one place is not changed accordingly.

Opacity

General
Follow Standard Conventions

Code at Wrong Level of Abstraction

Functionality is at wrong level of abstraction, e.g. a PercentageFull property

on a generic IStack<T>.

Always look for the root cause of a problem. Otherwise, it will get you again.

A class should have one, and only one, reason to change.

Most software defects are introduced when changing existing code. The
reason behind this is that the developer changing the code cannot fully
grasp the effects of the changes made. Clean code minimises the risk of
introducing defects by making the code as easy to understand as possible.

High Cohesion

Abstractness increases with stability

Boy Scout Rule

The design contains elements that are currently not useful. The added
complexity makes the code harder to comprehend. Therefore, extending
and changing the code results in higher effort than necessary.

time

Principles
Loose Coupling

Building, testing and other tasks take a long time. Therefore, these activities
are not executed properly by everyone and technical debt is introduced.

Needless Complexity

Optimal CoC

Taking a shortcut and introducing technical debt requires less effort than
doing it right.

low

low

Fragility

You cannot reuse parts of the code in other projects because of involved
risks and high effort.

Technical Debt

Clean Code Cheat Sheet

The software is difficult to change. A small change causes a cascade of

subsequent changes.

Immobility

actual
CoC

Stable Abstractions Principle (SAP)

The software breaks in many places due to a single change.

optimal Responsiveness

Responsiveness to change

Smells
Rigidity

Names have to reflect the entire functionality.

Standard Nomenclature Where Possible

Dont invent your own language when there is a standard.

Encodings in Names
No prefixes, no type/scope information

Understandability
Consistency

If you do something a certain way, do all similar things in the same way:
same variable name for same concepts, same naming pattern for
corresponding concepts.

Use Explanatory Variables

+
+

Boundary conditions are hard to keep track of. Put the processing for them
in one place, e.g. nextLevel = level + 1;

Prefer Dedicated Value Objects to Primitive Types

Instead of passing primitive types like strings and integers, use dedicated
primitive types: e.g. AbsolutePath instead of string.

Poorly Written Comment

Methods
Methods Should Do One Thing

Clean Code Cheat Sheet

The statements within a method should all be written at the same level of
abstraction, which should be one level below the operation described by
the name of the function.

Method with Too Many Arguments

Selector / Flag Arguments

public int Foo(bool flag)

Split method into several independent methods that can be called from the
client without the flag.

Inappropriate Static

Static method that should be an instance method

Source Code Structure

Vertical Separation

Refactor (or introduce) interfaces between components so that each

component can be tested in isolation of its environment.

6) Write Component Acceptance Tests

Clean Code: A Handbook of Agile Software Craftsmanship by Robert Martin

7) Decide for Each Component:

Refactor, Reengineer, Keep

Redesign classes within the component and refactor step by step (see
Refactoring Patters). Add unit tests for each newly designed class.

Exception Handling
Catch Specific Exceptions

Use ATDD and TDD (see Clean ATDD/TDD cheat sheet) to re-implement the
component.

8b) Reengineer Component

+

Catch exceptions as specific as possible. Catch only the exceptions for which
you can react in a meaningful manner.

Only catch exceptions when you can react in a meaningful way. Otherwise,
let someone up in the call stack react to it.

+
+

Exceptions should be thrown as early as possible after detecting an

exceptional case. This helps to pinpoint the exact location of the problem by
looking at the stack trace of the exception.

Using Exceptions for Control Flow

Swallowing Exceptions
Exceptions can be swallowed only if the exceptional case is completely
resolved after leaving the catch block. Otherwise, the system is left in an
inconsistent state.

8c) Keep Component

+
+
+

If you anticipate only few future changes to a component and the

component had few defects in the past, consider keeping it as it is.

Refactoring Patterns
Reconcile Differences Unify Similar Code

Change both pieces of code stepwise until they are identical. Then extract.

Isolate Change

First, isolate the code to be refactored from the rest. Then refactor. Finally,
undo isolation.

Migrate Data

Move from one representation to another by temporary duplication of data

structures.

Temporary Parallel Implementation

Refactor by introducing a temporary parallel implementation of an

algorithm. Switch one caller after the other. Remove old solution when no
longer needed. This way you can refactor with only one red test at a time.

Demilitarized Zone for Components

Nested code should be more specific or handle less probable scenarios than
unnested code.

Introduce an internal component boundary and push everything unwanted

outside of the internal boundary into the demilitarized zone between
component interface and internal boundary. Then refactor the component
interface to match the internal boundary and eliminate the demilitarized
zone.

Structure Code into Namespaces by Feature

Refactor before adding Functionality

Nesting

Keep everything belonging to the same feature together. Don't use

namespaces communicating layers. A feature may use another feature; a
business feature may use a core feature like logging.

+
+

Bibliography

8a) Refactor Component

Fail Fast

In a Coding Dojo, a group of developers come together to exercise their

skills. Two developers solve a problem (kata) in pair programming. The rest
observe. After 10 minutes, the group rotates to build a new pair. The
observers may critique the current solution, but only when all tests are
green.

Decide for each component whether to refactor, reengineer or keep it.

Using exceptions for control flow: has bad performance, is hard to

understand and results in very hard handling of real exceptional cases.

Variables and methods should be defined close to where they are used.
Local variables should be declared just above their first usage and should
have a small vertical scope.

Coding Dojo
+

Within a feature, identify the components used to provide the feature.

Prioritise components according to relevance for future development
(likelihood and risk of change).

5) Refactor Interfaces between Components

A developer walks a peer developer through all code changes prior to

committing (or pushing) the changes to the version control system. The
peer developer checks the code against clean code guidelines and design
guidelines.

Cover the features provided by a component with Acceptance Tests.

In an exceptional case, throw an exception when your method cannot do its

job. Don't accept or return null. Don't return error codes.

The class dependencies should not be tangled. There should be no cyclic

dependency chains. In a cycle there is no point to start changing the code
without side-effects.

Use Exceptions instead of Return Codes or null

Prevent usage. Return complex object holding all values, split into several
methods. If your method must change the state of something, have it
change the state of the object it is called on.

Tangles

Catch Where You Can React in a Meaningful Way

Prefer fewer arguments. Maybe functionality can be outsourced to a

dedicated class that holds the information in fields.

Method with Out/Ref Arguments

4) Identify Components

Use reference codes instead of enums if they have to be persisted. Use

polymorphism instead of enums if they define behaviour.

Commit Reviews

Refactor the boundaries of your system to interfaces so that you can

simulate the environment with test doubles (fakes, mocks, stubs).

2) Introduce Boundary Interfaces for Testability

Cover a feature with Acceptance Tests to establish a safety net for

refactoring.

How to Learn Clean Code

Pair Programming

Identify the existing features in your code and prioritise them according to
how relevant they are for future development (likelihood and risk of
change).

1) Identify Features

3) Write Feature Acceptance Tests

Replace Magic Numbers and Strings with named constants to give them a
meaningful name when meaning cannot be derived from the value itself.

Enums (Persistent or Defining Behaviour)

Two developers solving a problem together at a single workstation. One is

the driver, the other is the navigator. The driver is responsible for writing
the code. The navigator is responsible for keeping the solution aligned with
the architecture, the coding guidelines and looks at where to go next (e.g.
which test to write next). Both challenge their ideas and approaches to
solutions.

Comment holding information better held in a different system: product

backlog, source control. Use code comments for technical notes only.

Magic Numbers / Strings

Code that is not dead but does not add any functionality

Loops, exception handling, encapsulate in sub-methods.

Methods Should Descend 1 Level of Abstraction

Clutter

Eliminate duplication. Violation of the Dont repeat yourself (DRY)

principle.

A method can only work when invoked correctly depending on something

else in the same class, e.g. a DeleteItem method must only be called if a
CanDeleteItem method returned true, otherwise it will fail.

Delete unused things. You can find them in your version control system.

Violations of the Principle of Least Astonishment. What you expect is

what you get.

Hidden Logical Dependency

Useless Stuff
Dead Comment, Code

From Legacy Code to Clean Code

Always have a Running System

Change your system in small steps, from a running state to a running state.

Positive conditionals are easier to read than negative conditionals.

Maintainability Killers
Duplication

Too dense algorithms that lose all expressiveness.

Obvious Behaviour Is Unimplemented

Positive Conditionals

Inappropriate Information

Comment does not add any value (redundant to code), is not well formed,
not correct grammar/spelling.

Obscured Intent

if (this.ShouldBeDeleted(timer)) is preferable to if (timer.HasExpired &&

!timer.IsRecurrent).

Use locals to give steps in algorithms names.

Encapsulate Boundary Conditions

Conditionals
Encapsulate Conditionals

Legend:
DO
DONT

Refactor the existing code before adding new functionality in a way so that
the change can easily be made.

Small Refactorings
Only refactor in small steps with working code in-between so that you can
keep all loose ends in your head. Otherwise, defects sneak in.
This work by Urs Enzler is licensed under a Creative
Commons Attribution 4.0 International License.

Urs Enzler www.bbv.ch October 2014 V2.4

Kinds of Automated Tests

ATDD Acceptance Test Driven Development

Specify a feature first with a test, then implement.

TDD Test Driven Development

Write a unit test that reproduces the defect Fix code Test will succeed
Defect will never return.

POUTing Plain Old Unit Testing

Aka test after. Write unit tests to check existing code. You cannot and
probably do not want to test drive everything. Use POUT to increase sanity.
Use to add additional tests after TDDing (e.g. boundary cases).

Design for Testability

Constructor Simplicity

Objects have to be easily creatable. Otherwise, easy and fast testing is not
possible.

Constructor Lifetime

Pass dependencies and configuration/parameters into the constructor that

have a lifetime equal to or longer than the created object. For other values
use methods or properties.

Abstraction Layers at System Boundary

Clean ATDD/TDD Cheat Sheet

Use abstraction layers at system boundaries (database, file system, web

services, ...) that simplify unit testing by enabling the usage of fakes.

Structure
Arrange Act Assert

+
+

Create a test assembly for each production assembly and name it as the
production assembly + .Test/.Facts/ .

Test Namespace

+
+
+

Use the SetUp / TearDown methods only for infrastructure that your unit
test needs. Do not use it for anything that is under test.

Test Method Naming

+
+

Give the variable holding the System Under Test always the same name (e.g.
testee or sut). Clearly identifies the SUT, robust against refactoring.

Naming Result Values

Give the variable holding the result of the tested method always the same
name (e.g. result).

Anonymous Variables

Always use the same name for variables holding uninteresting arguments to
tested methods (e.g. anonymousText, anyText).

Dont Assume
Understand the Algorithm

Just working is not enough, make sure you understand why it works.

Incorrect Behaviour at Boundaries

Always unit test boundaries. Do not assume behaviour.

Use a dynamic fake framework for fakes that show different behaviour in
different test scenarios (little behaviour reuse).

Manually Written Fakes

Use manually written fakes when they can be used in several tests and they
have only little changed behaviour in these scenarios (behaviour reuse).

Mixing Stubbing and Expectation Declaration

Make sure that you follow the AAA (arrange, act, assert) syntax when using
fakes. Dont mix setting up stubs (so that the testee can run) with
expectations (on what the testee should do) in the same code block.

Checking Fakes instead of Testee

Tests that do not check the testee but values returned by fakes. Normally
due to excessive fake usage.

Excessive Fake Usage

Hidden Test Functionality

Bloated Construction
Unclear Fail Reason

+
+

Isolated testee: Clear where the failure happened.

Isolated test: No dependency between tests (random order).

TDD Principles
A Test Checks One Feature

Tiny Steps
Keep Tests Simple

Whenever a test gets complicated, check whether you can split the testee
into several classes (Single Responsibility Principle)

Prefer State Verification to Behaviour Verification

Unit Test Smells

Test Not Testing Anything

Use behaviour verification only if there is no state to verify. Refactoring is

easier due to less coupling to implementation.

Too Large Test / Assertions for Multiple Scenarios

Test Domain Specific Language

Use test DSLs to simplify reading tests: builders to create test data using
fluent APIs, assertion helpers for concise assertions.

TDD Process Smells

Using Code Coverage as a Goal

A valid test that is, however, too large. Reasons can be that this test checks
for more than one feature or the testee does more than one thing (violation
of Single Responsibility Principle).

Use code coverage to find missing tests but dont use it as a driving tool.
Otherwise, the result could be tests that increase code coverage but not
certainty.

Checking Internals

No Green Bar in the last ~10 Minutes

A test that accesses internals (private/protected members) of the testee

directly (Reflection). This is a refactoring killer.

Test Only Running on Developers Machine

A test that catches exceptions and lets the test pass.

Skipping Something Too Hard to Test

Make it simpler, otherwise bugs will hide in there and maintainability will
suffer.

Organising Tests around Methods, Not Behaviour

Extend Test

Extend an existing test to better match real-world scenarios.

Another Test

If you think of new tests, then write them on the TO DO list and dont lose
focus on current test.

Learning Test

Write tests against external components to make sure they behave as

expected.

Green Bar Patterns

Fake It (Til You Make It)

Return a constant to get first test running. Refactor later.

Triangulate Drive Abstraction

+

Write test with at least two sets of sample data. Abstract implementation
on these.

Obvious Implementation

If the implementation is obvious then just implement it and see if test runs.
If not, then step back and just get test running and refactor then.

+
+
+
+

One to Many Drive Collection Operations

First, implement operation for a single element. Then, step to several

elements (and no element).

Acceptance Test Driven Development

Use Acceptance Tests to Drive Your TDD tests

Acceptance tests check for the required functionality. Let them guide your
TDD.

User Feature Test

An acceptance test is a test for a complete user feature from top to bottom
that provides business value.

Automated ATDD

Use automated Acceptance Test Driven Development for regression testing

and executable specifications.

Component Acceptance Tests

Write acceptance tests for individual components or subsystems so that

these parts can be combined freely without losing test coverage.

Simulate System Boundaries

Simulate system boundaries like the user interface, databases, file system
and external services to speed up your acceptance tests and to be able to
check exceptional cases (e.g. a full hard disk). Use system tests to check the
boundaries.

Acceptance Test Spree

Do not write acceptance tests for every possibility. Write acceptance tests
only for real scenarios. The exceptional and theoretical cases can be
covered more easily with unit tests.

Dont assume, check it. If it is easy, then the test is even easier.

A test that fills the console with text probably used once to manually
check for something.

Test Swallowing Exceptions

Refactoring is an investment in the future. Readability, changeability and

extensibility will pay back.

Skipping Something Too Easy to Test

Test contains information that is not relevant to understand it.

Chatty Test

Only if the test fails, then new code is required. Additionally, if the test
surprisingly does not fail then make sure the test is correct.

Not Spending Enough Time on Refactoring

A test that checks more than it is dedicated to. The test fails whenever
something changes that it checks unnecessarily. Especially probable when
fakes are involved or checking for item order in unordered collections.

Irrelevant Information

Make small steps to get feedback as fast and frequent as possible.

Not Running Test Before Writing Production Code

A test that is dependent on the development environment and fails

elsewhere. Use continuous integration to catch them as soon as possible.

Test Checking More than Necessary

Make tiny little steps. Add only a little code in test before writing the
required production code. Then repeat. Add only one Assert per step.

Partial Test

Write a test that does not fully check the required behaviour, but brings you
a step closer to it. Then use Extend Test below.

A test checks exactly one feature of the testee. That means that it tests all
things included in this feature but not more. This includes probably more
than one call to the testee. This way, the tests serve as samples and
documentation of the usage of the testee.

Tests are written at the right time (TDD, DDT, POUTing)

Test Needing Excessive Setup

Tests depend on special logic in production code.

Erratic Test

Pick a test you are confident you can implement and which maximises
learning effect (e.g. impact on design).

Tests should not have any conditional test logic because its hard to read.

Sometimes passes, sometimes fails due to left overs or environment.

Timely

Red Bar Patterns

One Step Test

Split test or use assertion messages.

Unit Test Principles

Fast

Self-Validating

The construction of dependencies and arguments used in calls to testee

makes test hardly readable. Extract to helper methods that can be reused.

Test Logic in Production Code

Repeatable

Do not test setters and getters in isolation, test the scenario they are used
in.

Test functionality hidden in either the SetUp method, base class or helper
class. The test should be clear by looking at the test method only no
initialisation or asserts somewhere else.

If your test needs a lot of fakes or fake setup, then consider splitting the
testee into several classes or provide an additional abstraction between
your testee and its dependencies.

Isolated

A test that checks something no longer required in the system. May even
prevent clean-up of production code because it is still referenced.

Conditional Test Logic

A test that needs dozens of lines of code to set up its environment. This
noise makes it difficult to see what is really tested.

Test and resource are together: FooTest.cs, FooTest.resx

Naming
Naming SUT Test Variables

Obsolete Test

Passing test that at first sight appears valid but does not test the testee.

Use a pattern that reflects behaviour of tested code, e.g.

Behaviour[_OnTrigger][_WhenScenario] with [] as optional parts.

Resource Files

No manual test interpretation or intervention. Red or green!

Unit test methods show all parts needed for the test. Do not use SetUp
method or base classes to perform actions on testee or dependencies.

SetUp / TearDown for Infrastructure Only

Faking Framework

No assumed initial state, nothing left behind, no dependency on external

services that might be unavailable (databases, file system ).

Put the tests in the same namespace as their associated testee.

Unit Test Methods Show Whole Truth

A test that tests a completely different testee than all other tests in the
fixture.

Unit tests have to be fast in order to be executed often. Fast means much
smaller than seconds.

Structure the tests always by AAA. Never mix these three blocks.

Test Assemblies (.Net)

Test Not Belonging in Host Test Fixture

+

Use fakes to simulate all dependencies of the testee.

Red green refactor. Test a little code a little.

DDT Defect Driven Testing

Faking (Stubs, Fakes, Spies, Mocks, Test Doubles )

Isolation from environment

Legend:

DO
DONT

These tests are brittle and refactoring killers. Test complete mini use
cases in a way which reflects how the feature will be used in the real world.

Continuous Integration
Pre-Commit Check

ATDD, TDD cycle

+

Run all unit and acceptance tests covering currently worked on code prior to
committing to the source code repository.

Post-Commit Check

Write acceptance criteria for user story

Define examples

Write acceptance test skeleton

The whole team defines acceptance criteria for

user stories.

The whole team defines examples for acceptance

criteria used to show that code works.

Map the examples into an empty specification/test in your acceptance

test framework (Gherkin, MSpec/xBehave classes and statements )

Run all unit and acceptance tests on every commit to the version control
system on the continuous integration server.

Communicate Failed Integration to Whole Team

You need to build up knowledge to implement the

acceptance test.

Whenever a stage on the continuous integration server fails, notify whole

team in order to get blocking situation resolved as soon as possible.

Explore design

Build Staging

Implement a Spike to gather enough knowledge

so you can design a possible solution.

Split the complete continuous integration workflow into individual stages to

reduce feedback time.

Automatically Build an Installer for Test System

Make an initial design

Roughly design how you want to implement the new functionality,
especially the interface for your acceptance test (how to call and verify
functionality).

Refactor

Automatically build an installer as often as possible to test software on a

test system (for manual tests, or tests with real hardware).

Continuous Deployment

Refactor existing code to simplify introduction of new functionality. Run

all tests to keep code working.

Install the system to a test environment on every commit/push and on

manual request. Deployment to production environment is automated to
prevent manual mistakes, too.

Write an acceptance test

Succeeded, not all

acceptance tests
implemented yet

Succeeded

Add arrange, act and assert parts to the acceptance test skeleton (Given,
When, Then or Establish, Because, It ).

Test Pyramid

Run acceptance test

Run all acceptance tests

Succeeded and all
examples tested
Failed

Failed
Make error reason obvious
The failing test should state what went wrong so you dont have to
debug the code.

You have no class

design idea

ATDD

You have a class

design idea

Constraint Test = Test for non-functional requirements.

Spike a solution

Make initial or update class design

Implement a Spike to get the acceptance test

running so that you get an initial design.

Design how you want to implement the new

functionality.

Succeeded,
code clean,
TO DO list
empty

Do per class

TO DO list

Bibliography

Add missing test when you think of one

Remove test when written

Test Driven Development: By Example by Kent Beck

We write the TO DO list into the same file as the

unit test with // TODO:

ATDD by Example: A Practical Guide to Acceptance Test-Driven

Development by Markus Grtner

Write a test

The Art of Unit testing by Roy Osherove

Pick test with the following priority:
1) Prove that the code is making a hard coded
assumption.
2) Prove that something is wrong.
3) Prove that something is missing.

xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros

TDD

Clean ATDD/TDD Cheat Sheet

You have enough knowledge to

implement the acceptance test.

Add a minimal test or make a minimal change to

an existing test (< 10 minutes).

Succeeded,
code clean,
TO DO list
not empty

Run test

Failed
Make error reason obvious
The failing test should state what went wrong so
you dont have to debug the code.

Failed

Succeeded

Run all tests

Clean up code

Write code
Write as little code as possible to make the test
pass.

Succeeded,
code not clean

Apply clean code guidelines. Redesign classes as

needed. (< 10 minutes).

Legend:
DO
DONT

This work by Urs Enzler is licensed under a Creative

Commons Attribution 4.0 International License.

Urs Enzler www.bbv.ch October 2014 V2.4