simple testable code

Félix-Étienne Trépanierdeveloper @wajam

http://musicdrivendevelopment.com

_why?

maintainabilityand

evolution

ingredients not recipe

think    |    follow

coding process

understand---

apply

guard rails design and programming

even if tested, bad code kills bad unit test slows you down

what and how

TDD is very similar to getting things done with small children around. I just ask myself, "Now what was I trying to do?" every 5 minutes.

@carinmeier

production code

focus on...

core values

simplicity over flexibility

concreteness over abstraction

soft-coupled tests over full code coverage

test aware dev over test first dev

simple code

Aesthetic simplicity

• clean

• formatted

Cognitive simplicity

• clear concepts

• logically organized

• No unecessaryindirection

• small state space

clean code

no duplicate codeprecise and explicit

consistentsingle purpose artifacts

simple code

values are simpler than objectdata structures are simpler than classes

stateless is simpler than stateful

• Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin

• Simple Made Easy, Rich Hickey,  http://www.infoq.com/presentations/Simple-Made-Easy

• The Master, The Expert, The Programmer, Zed Shaw, http://zedshaw.com/essays/master_and_expert.html

references

by @alex_normand

refactoring can save you

test in isolation

speed

control

stability

all about dependencies

The key to write testable code is to inject some of the class dependencies via constructor, method parameters (or setter methods).

In the test code, test objects are passed to the class under test.

static dependencies

Example: MessageSender.java

The problem is not to depend on concrete classes, but to have static dependencies.

The new operator is static.

test code paradox

test code is strongly coupled to the production code

test code is code!

use test libraries

keep test code clean and simple

use the right test object

dynamic mock: Provided by unit test libraries such as Mockito. Simple to use and limit the amount of test code to a minimum.

production code: Add dependencies to the production code. Easier with behavior-less classes such as data holder.

hand coded mock: May be needed if behavior to mock is complex. Can be really painful to maintain.

assert behavior not implementation

• Testing implementation makes the test code fragile

• Verify return values and mandatory side effects

• Avoid asserting more than needed• One assert per test?

easy with EasyMock

assert only what is needed

stateless

Example: Statefull/StatelessProcessor.java

Stateless classes have no state space.

Stateless classes have do not worry about multithreading.

Stateless classes are simpler to setup for test.

summary

• aesthetic simplicity• cognitive simplicity• refactoring to keep code simple• inject dependencies• minimal test code• behavior validation