BEHAVIOUR DRIVEN REFACTORINGOR

I AM A PROGRAMMER, WHAT THE HELL DO I HAVE TO TEST?

Pedro Ballesteros@pmbah

Hi, we’re doing TDD

Really?, we too

How are you coding your mocks?

No mocks, we’re testing against

external systems

Don’t you write unit tests?

Well, actually, we’re doing BDDBDD! Wow!

Our TDD is already obsolete!

ARE WE THINKING ABOUT THE SAME WHEN SAYING “TEST” OR “DRIVEN”?

ATDD TDD

BDD

BDA

STDD CTDD

BDS BDP

TDD

BDD

BDA

STDD CTDD

BDS BDP

ATDD

TEST

TEST

TEST

TEST

TEST

TEST

BEHAVIOUR

BEHAVIOURBEHAVIOUR

BEHAVIOUR

DRIVEN

DRIVEN DRIVEN

DRIVEN

DRIVEN

DRIVEN

WE’RE DOING BEHAVIOUR DRIVEN REFACTORING

WHAT’S REALLY BDD?

HAVE BDD CHANGED THE RULES FOR PROGRAMMERS?

WE CONTINUE USING TDD RULES BUT WITH OTHER WORDS

WHAT’S REALLY BDD? Dan North (http://dannorth.net/introducing-bdd/) Problems teaching Test Driven Development (TDD).

Where to start, what to test and what not to test. How much to test in one go, what to call their tests.

Test methods names should be sentences. Remove the test word changing method names into regular text.

Behaviour: my code should do something. Verifying behaviours instead of testing methods, classes or modules. shouldDoX instead testX

Requirements are behaviour, too. What’s the next most important thing the system doesn’t do? Scenarios: Given… When… Then…

The problem was the word TEST itself

WHAT’S REALLY BDD?

BDD provides a “ubiquitous vocabulary”

for both analysis and implementation

We all can now build the system talking of BEHAVIOURS

Reducing the gap between “the what” and “the how”

WHAT’S REALLY BDD?

SPECIFICATION/ANALYSIS

Behaviour Driven Development

= Acceptance Test Driven Development

+ Test Driven Development

IMPLEMENTATION/CODINGBEHAVIOUR DRIVEN ANALISYS (BDA)

BEHAVIOUR DRIVEN SPECIFICATION (BDS)

=ATDD

BEHAVIOUR DRIVEN PROGRAMMING (BDP)

=TDD

WHAT’S REALLY BDD?

SPECIFICATION/ANALYSIS

Executable SpecificationFeature: Horoscope tells my luck In Order to decide what to do As a superstitious user I want to know my luck in life

Scenario: Birthday based luck Given my birthday When I am born in summer Then my luck it is 10

BUSSINESS VOCABULARY

WHAT’S REALLY BDD?IMPLEMENTATION/CODING Automated Debugging

Continuous Refactoringpublic class SmartDateParserBehaviours { @Test public void should_parse_short_format(String birthday) { // TODO }}

public class HoroscopeBehaviours { @Test public void luck_should_be_10_when_summer(Date date) { // TODO assertThat(luck, is(10)); }}

describe(‘horoscope', function(){ describe(‘luck', function() { it('should return be 10 when born in summer', function(){ // TODO luck.should.equal(10); }) it('should return be 1 when born in winter', function(){ // TODO luck.should.equal(1); }) })})

IMPLEMENTATION VOCABULARY

MOCHA (JS)

JUNIT

(JAVA)

We still continue coding with TDD rules

At the implementation levelBDD is just TDD using the proper words

HAVE BDD CHANGED THE RULES FOR PROGRAMMERS?

SPECIFICATION (BDA)

IMPLEMENTATION (BDP)

WHAT’S TDD?

WHAT’S TDD?Test Driven Development “mantra”: red - green - refactor

WHAT’S TDD?

AUTOMATED DEBUGGING

WHAT’S TDD?

AUTOMATED DEBUGGING

TDD CYCLE

Each iteration no more than ten code editions. New lines of functional code. Bug fixing. Refactoring.

With 2 minutes per iteration. Tests run 240 times in 8 hours.

Tests must be F.I.R.S.T

WHAT’S TDD?

Test First Development + Refactoring

Test Driven Development =

WHAT’S TDD?

“Test Driven Development is a Development Methodology”

“It is not a Testing Methodology”

“The act of writing a unit test is more an act of design than of verification. It is also more an act of documentation than of verification. The act of writing a unit test closes a remarkable number of feedback loops, the least of which is the one pertaining to verification of function.”

Robert C. Martin (aka. Uncle Bob)

CONTINUOUS REFACTORING

If you are not refactoring in every iteration you are not doing TDD

REFACTOR IS THE UNQUESTIONABLE STAR OF THE PICTURE

First make it work, then make it right, then make it small and fast

It is in the soul of Extreme Programming and AgileYAGNI - Your ain’t gonna need it

Rapid FeedbackEmbrace the change

REFACTOR IS THE UNQUESTIONABLE STAR OF THE PICTURE

PROGRAMMERS MUST WORK WITH

BEHAVIOUR DRIVEN REFACTORING

DEATH OF THE TECHNICAL DEBT

BUT WHAT TEST DO I HAVE TO CODE?

SCOPE PURPOSE

VISIBILITY

SYSTEM TESTS

INTEGRATION TESTS

UNIT TESTS

ACCEPTANCE TESTS

NON FUNCTIONAL TESTS

PERFORMANCE STRESS

LOAD . . .

FUNCTIONAL TESTS

USER INTERFACE TESTS

WHITE BOX TESTS

BLACK BOX TESTS

BUT WHAT TEST DO I HAVE TO CODE?

Acceptance Tests

System Tests

UI Tests

Integration Tests

Unit Tests

Unit Tests

Integration Tests

BUT WHAT TEST DO I HAVE TO CODE?

Small Scaled Tests Micro Tests Isolated Object Tests

IMPORTANT TO MOCK A LOT

“TEST MUST BE F.I.R.S.T”

F.I.R.S.T

FAST

INDEPENDENT

REPEATABLE

SMALL

TRANSPARENT

AVOID TDD ANTIPATERNS Testing dependencies instead of the Subject Under Test. Excessive Mocking (lack of enough refactoring). Several test cases and verifications in a single test. Tests that depend of data created by previous tests. Tests with sequential names (test1, test2, testN). Tests accessing to external systems. Lack of refactoring. Not clear tests (difficult to understand). Ignoring F.I.R.S.T. properties. Writing Unit Tests over existing or legacy code.

HOW MUCH TESTING? THE TRADITIONAL TESTING PYRAMID

UNIT TESTS

INTEGRATIONTESTS

SYSTEM, UI, ACCEPTANCE TESTS

HOW MUCH TESTING?

Automated tests were considered expensive to write and were often written months, or in some cases years, after a feature had been programmed.

One reason teams found it difficult to write tests sooner was because they were automating at the wrong level.

An effective test automation strategy calls for automating tests at three different levels, as shown in the figure, which depicts the test automation pyramid.

MIKE COHN’S TESTING PYRAMID

Small in number

At least one per story

Loads of them

* http://blog.mountaingoatsoftware.com/the-forgotten-layer-of-the-test-automation-pyramid/

UI TESTS

ACCEPTANCE TESTS

UNIT TESTS

WATCHING THE COVERAGEWATCH THE COVERAGE METRIC

SOME CODE MUST NOT HAVE UNIT TESTING COVERAGE

Domain Model Objects Code that access external systems (database or rest clients)

Acceptance Tests Integration Tests (if I can dedicate resources to the task)

When unit testing it is too much expensive

DON'T USE TDD WHEN DOESN'T DRIVE YOUR DEVELOPMENT

REFACTORING

REFACTORING

NOW THAT IT WORKS, MAKE IT RIGHT, SMALL AND FAST“We had license to go fast because we knew we have good unit test

coverage and we are doing continuous refactoring”

Remove code smells, repeated code and copy & paste. Extract reusable code in common libraries. Improve architecture, design and codification. Produce legible, maintainable and extensible code. Make your code clean.

YOU CAN DRIVE REFACTORING USING S.O.L.I.D

LEARNED LESSONS: If your unit tests are getting so complex, probably your design is not good, you are not refactoring.

S.O.L.I.D.

SINGLE RESPONSIBILITY PRINCIPLE

OPEN/CLOSED PRINCIPLE

LISKOV SUBSTITUTION PRINCIPLE

INTERFACE SEGREGATION PRINCIPLE

DEPENDENCY INVERSION PRINCIPLE

(*) Formulated in 2000 by Robert C. Martin

REFACTORING

UNIT TESTS ARE NOT SECOND CLASS CITIZENS Tests are part of the system, they are specifications. The tests are the most important component in the system. They are more important than the production code.

UNIT TESTS MUST BE REFACTORED, TOO

Robert C. Martin (aka. Uncle Bob)

http://blog.8thlight.com/uncle-bob/2013/09/23/Test-first.html

“The tests enable the team to go fast and the system to stay healthy. Therefore those tests are an integral, and critical, part of the system. As such, they deserve to be maintained to the same level of quality as the production code. Indeed, perhaps the tests deserve even more attention than the production code since the quality of the production code depends on the tests; but the quality of the tests does not depend on the production code.”

TO MOCK OR NOT TO MOCK

MOCKING Isolate unit tests from external systems. Satisfy F.I.R.S.T properties. Drive or force the running of the code under test. Interaction (collaboration tests) instead of State Verification.

YOU CAN DECIDE TO TRUST YOUR DEPENDENCIES

Dependencies have they own unit tests. Difficult to locate the cause of test failures. But do not turn a test in the tests of the dependencies.

COLLABORATION TESTS AND CONTRACT TESTS

15 TESTS10 TESTS

Integrated Tests: 10 X 15 = 150 Unit Tests: 10 + 15 = 25 What if the deep are 5 and each one has 10 behaviours

10^5 = 10000 Integrated Tests Testing all possible paths is nearly impossible and has a high

effort and high time cost.

DO WE HAVE TO TESTS ALL POSSIBLE PATHS?

COLLABORATION TESTS AND CONTRACT TESTS

15 TESTS10 TESTS

Remove all integrated tests and mock dependencies. Collaboration tests of Module A require to program

some responses in the Mock of the Module B. Those programmed responses are the specification of the

Contract Tests for the future Module B. If your code has bugs you are forgetting some collaboration

tests or not writing all the contract tests specified by mocks.

COLLABORATION TESTS AND CONTRACT TESTS

Integrated Tests Are Scam Series by J. B. Rainsberger http://www.jbrains.ca/permalink/integrated-tests-are-a-scam-part-1 http://blog.thecodewhisperer.com/blog/categories/integrated-tests-are-a-scam http://www.infoq.com/presentations/integration-tests-scam

INTEGRATED TESTS ARE SCAM SERIES

J. B. Rainsberger (aka JBrains)

THANKS

Pedro Ballesteros@pmbah

Would you like to know more?

Look for a good TDD course, go to a Coding Dojo and do a lot of Code Katas.