los diez mandamientos de tdd

agile software development & services

Los Diez Mandamientos de TDD

Scrum Bolivia DayHernán Wilkinson

Twitter: @HernanWilkinsonBlog: objectmodels.blogspot.com

www.10pines.com

What is TDD?

This is NOT TDD, this is how you do it!

So… what is the ESENCE of TDD

TDD is not about testing onlyIt is more than that…

TDD is about doing incremental problem solving guided by concrete

examples

We are used to incremental development (cycles/iteration), but not incremental design/programming

TDD brings testing to development cycle

Analisys

DesignProgram.

Testing

TDD brings testing to development cycle

Analisys

Design

Program.

Testing

TDD brings testing to development cycle

1. Tests are explicit, not implicit anymore

2. Tests run automatically, not because a person tests

3. Tests bring requirements to live!

TDD “SINCERIZA” programmers about testing

A programmer that is not a good tester is not a good programmer

Good Programmer = Good Tester

=

TDD is a cultural change… a big one

The Commandments

1. Management ones2. Technical one

About testing

About design

(Sadly, they are more than ten…)

The Management Commandments

You shall not expect your developers do TDD because it is God, I mean Good

You shall not expect your developers do TDD because it is God, I mean Good

1. It is a Cultural Change!

2. Cultural changes do not happen by themselves

3. As manager, you have to provide the environment for the change and support it

4. … and yes sometimes you have to be tuff, it is part of being a leader

5. It is great start doing Pair Programming!

You shall provide time to do TDD

You shall provide time to do TDD

1. YES!! Doing TDD TAKES TIME!!! and more at the beginning… It is a cultural change!

2. BUT… the time you “invest” doing TDD gets pay in the mid-term

3. Finding a bug running the tests during a regression has no price!… for the rest you have mastercard

You shall not send mixed messages

stopping TDD when time looks not

enough

You shall not send mixed messages stopping TDD when time looks not

enough

1. The problem is the PLAN… it is a PLAN for God sake!

2. If you HAVE TO do it, provide a reasonable explanation, talk to your team!

You shall not expect no errors at all

You shall not expect no errors at all

1. Testing is not a “formal verification technique”

2. You can not say anything about what it is not tested… that is why it is important to write the test first

3. DO NOT STOP DOING TDD because you got some errors on production

4. Use Mutation Testing/Coverage to test your tests!!

You shall not expect one hundred percent coverage

You shall not expect one hundred percent coverage

1. Sometimes it is too costly to automatize certain tests

2. Coverage is not a good measure of testing quality

3. 100% coverage is impossible when just starting to do TDD

You shall not remove the QA team due to TDD

You shall not remove the QA team due to TDD

1. Because TDD is not about testing only!

2. Because TDD does not test UI, user experience, performance, scalability, etc, etc

3. TDD helps QA to concentrate on the real and important issues

You shall wait for your team to be “test infected”

You shall wait for your team to be “test infected”

1.Experience is IMPORTANT. Wait your team to become expert, it will not happen in a week2.Do not mix senior programmers with junior programmers, but semi-senior programmers with both (Pragmatic thinking and learning)

The Technical Commandments

You shall write the test first

You shall write the test first

1. Is about incremental design and programming

2. Is not about providing a generic implementation with one case

3. It is not only about not doing what is not necessary

4. If you don’t do it, you will lie to yourself and forget to write some tests

5. If you don’t do it, you are just testing

6. IT IS THE MOST DIFICULT PART

You shall assert in your tests

You shall assert in your tests

1. Test without assertion is not a test, it is just a mere observation

2. If you don’t have an assertion, re-think the whole test or remove it

You shall not write many tests and then try to run them

You shall not write many tests and then try to run them

1. Use a notepad to write the description of the tests that came to your mind

2. Wrong design decisions (which is common when not knowing the whole picture) will affect all the tests you wrote

3. You have to start feeling comfortable with the “uncertainty”… it is about incremental design/programming

You shall not believe that TDD is about unit testing only

(with the classical definition of unit testing)

You shall not believe that TDD is about unit testing only

1. TDD is not only about testing a method or a class

2. The more important tests are those that verify a functionality of the system

3. Unit Test = Run fast! (less than 100 milliseconds)

You shall not name your tests after the HOW but after the WHAT

You shall not name your tests after the HOW but after the WHAT

1. Wrong name: testAccountBalanceT

oo generic, it is not a concrete example

2. Good name: testGivenAnAccountWithoutTransactionsWhenAskedForItsBalanceThenItShouldReturnCeroIt is a concrete example

3. Test names are LONG! and they should be

You shall verify one case per test

You shall verify one case per test

1. To keep tests simple 2. If a test fails the you know by the

test name what it is wrong3. It is difficult to name a test that

verifies more than one case smell

You shall not test twice the same

You shall not test twice the same

1. To simplify test maintenance2. To keep consistency

You shall keep your tests clean, they are another system

You shall keep your tests clean, they are another system

1. The tests are another system using yours!

2. Test maintenance can get costly if you don’t keep them clean

You shall not start testing interfaces, you shall start testing the business

model

You shall not start testing interfaces, you shall start testing the business

model

1. Because you have to start with the simplest test possible

2. Because you want immediate feedback3. Because is the business model what is

important regardless any interface (UI, rest, webservices, etc)

You shall not TDD using relational databases

You shall not TDD using relational databases

1. Relational databases are SLOW (from a testing point of view)

2. Relational databases make your development harder

3. Relational databases misguide your design

4. Relational databases are a solution to a computable problem: persistence

5. Test but not TDD using relational database

You shall not test using external systems

You shall not test using external systems

1. A Relational Database is an external system!

2. External systems make your test slow3. External systems avoid your test to be in

“control of everything”4. External systems create an unnecessary

coupling with your tests5. Simulate external systems

You shall not mock your wife!

You shall not mock your wife!1. There are certain things you should not

simulate!2. Do not simulate your business objects3. Only simulate what is out of your

system’s reach4. If scenarios are difficult to create, create

scenarios factories!5. Objects collaborate, they don’t live alone

by themselves

You shall understand that TDD does not imply good design

You shall understand that TDD does not imply good design

1. Good designs are made by good designers

2. TDD implies less couple designs but not good ones

3. TDD does not imply not to think!4. TDD does not imply not to use good

design techniques or rules

You shall not worry about performance at the beginning

You shall not worry about performance at the beginning

1. You shall not worry about performance, persistence, scalability, etc. (the computational problems)

2. You shall worry about modeling the business first!

You shall love testing as much as programming

You shall love testing as much as programming

1. Because as programmers, we always testWe do it implicitlyWe do it in our heads

2. Testing is part of development3. GOOD PROGRAMMER = GOOD

TESTER

And now …

(Nota: El Papa es Argentino… mais Deus é brasileiro - Dilma dixit)

Los Diez Mandamientos

1. Amarás TDD sobre todas las cosas2. No usarás el nombre de TDD en vano3. Festejarás cuando uses TDD4. Honrarás a tus tests y tus test suites.5. No matarás a QA

Los Diez Mandamientos

6. No cometerás adulterio con tus programas

7. ROBARAS las ideas de los tests de otros8. No mentirás en tus tests9. DESEARAS los tests de otros10.No codiciarás la falta de testing de los

otros

Enseñamos estos y otros cursos como:• Diseño Avanzado con Objetos I• Diseño Avanzado con Objetos II• Construcción de Soft. con TDD• TDD Avanzado … y más

http://www.10pines.com/content/cursosdisponibles

Questions?

agile software development & services

Muchas gracias!

info@10pines.comwww.10Pines.com

twitter: @10Pines

Argentina

Tel.: +54 (11) 4780-2460Alem 693, 5BBuenos Aires