DOJO (COMING SOON)

https://github.com/guillaumeagile/AtelierCleanArchitecture2013/

/c#/CLEAN-OneBrandTwoShopsTwoUI_WithTests

TESTING GOALS

1. Programmer errors

2. Design errors

3. Requirements errors

4. Systemic errors

http://www.qualitystreet.fr

UNIT OR NOT UNIT ?

PROGRAMMER ERRORS

Unit Tests guarantee safe Refactoring

DES TESTS RAPIDES

… ou rien !

ISOLATION

One thing at a time!

COMPLEXITY

In French : Combinatoire

LA COMBINATOIRE FAIT PEUR

INTEGRATION TESTS

5 composants qui ont chacun 50 cas de

fonctionnements

2 composants qui ont chacun 11 cas

différents

INTEGRATION TESTS

INTEGRATION TESTS

UNITAIREMENT

5 x 50 = 250

2 x 11 = 22

Total: 277 tests

REDUCE COMPLEXITY

Where does it come from?

FROM THIS?

OR THIS?

GRAVITY

Do you know

Newton?

A DATACENTRIC ARCHITECURE

DATABASE IS A

FROM THE CODE POINT OF VIEW

Database is a

Storage

Persitence

Service

Plug-in

THE DATABASE IS A

Detail !

MAKES YOU THINK TWICE

Which data to keep in your test and why?

Which data to keep in your code and why?

ISOLATE IT

I don’t care

I want objects

I want to code

I want an application

Test One Thing at a Time

Minimize Dependencies

CHANGE THE WAY YOU CODE

PATTERN 1: REMOVE THE CORE DATA

DEPENDENCE

ABSTRACT DATA TO A MODEL

REPOSITORY PATTERN

DB = persistence

No more!

PATTERN 2: CONSTRUCT AN IN-MEMORY CORE

DATA STACK.

MOCK IT, FAKE IT, DEFER IT

Find a gateway

MAKES YOUR LIFE EASIER

I must set up a Test DB

What if someone else add sh*t in your test DB?

Test DB is growing and growing…

What if you loose you DB connection?

What if you loose it all?

NO DEPENDENCE ON EXTERNAL STATE

• the tests must run the same

way every time they run

IDEMPOTENT TEST

you are able to rerun something because the process of

running it did not change its state.

CLOSE APPROXIMATION TO THE APPLICATION

ENVIRONMENT

With a Fake or a Mock

WHAT ABOUT CONSTRAINS

They are logic in data

They are impossible to test

They are hard to maintain

WHAT ABOUT TRANSACTIONS

Do you really need ACID ?

WHAT ABOUT STORED PROCEDURES

They are pain in the ass!

They embed logic with data

They are hard to test

They are hard to maintain

WHAT ABOUT TRIGGERS

They are evil

DID I SAY NO (TO) SQL?

CHANGE YOUR VIEW ON DATA

Is the DBA your master?

STOP DATA FASCISM

Stop thinking MDD (Model Driven Design)

MCD in French

Think DDD

DOMAIN

DRIVEN

DESIGN

FOCUSED INTEGRATION TESTS

EXPLORATORY TESTING

ONE BUG = ONE MISSING TEST

No unit test can tell you that you need more tests…

Exploration can.

THERE’S ALWAYS A PATTERN

To be more and more isolated (SRP/OCP/LSP/ISP/DI)

• Factory

• Facade

• Visitor

• IoC ( Depency Injectors)

• ….

• MVP

• Humble Dialog ….

ALL IS A MATTER OF CONCEPTS

Abstraction & Architecture

CHANGE THE WAY YOU CODE

ALWAYS CODE AS YOU TEST: in isolation

-> Domain knows nothing about the infrastructure.

CREDITS

http://visualstudiomagazine.com/articles/2009/09/01/eliminat

e-database-dependencies-in-test-driven-development.aspx

http://codebetter.com/jeremymiller/2005/10/12/unit-testing-

business-logic-without-tripping-over-the-database/

http://stackoverflow.com/questions/145131/whats-the-best-

strategy-for-unit-testing-database-driven-applications

http://www.jamesshore.com/Blog/Alternatives-to-Acceptance-

Testing.html

http://www.agiledata.org/essays/agileDataModeling.html

http://martinfowler.com/bliki/OrmHate.html

http://www.adam-

bien.com/roller/abien/entry/how_evil_are_actually_data