In a sea of "Driven Development" methodologies, what is the best to drive the coding of my software. I was using TDD but all people is talking of BDD lately. Have the rules changed at the implementation level?

1. BEHAVIOUR DRIVEN REFACTORING
OR
I AM A PROGRAMMER, WHAT THE HELL DO I HAVE TO TEST?
Pedro Ballesteros
@pmbah

2. 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?
BDD! Wow!
Our TDD is already
obsolete!
Well, actually,
we’re doing BDD
ARE WE THINKING ABOUT THE SAME WHEN SAYING
“TEST” OR “DRIVEN”?

5. WE’RE DOING
BEHAVIOUR DRIVEN REFACTORING

6. WHAT’S REALLY BDD?
HAVE BDD CHANGED THE RULES FOR PROGRAMMERS?
WE CONTINUE USING TDD RULES BUT WITH OTHER WORDS

7. 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.
The problem was the word TEST itself

Test methods names should be sentences.


Behaviour: my code should do something.



Remove the test word changing method names into regular text.
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…

8. 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”

9. WHAT’S REALLY BDD?
Behaviour Driven Development
=
Acceptance Test Driven Development
+
Test Driven Development
SPECIFICATION/ANALYSIS
BEHAVIOUR DRIVEN ANALISYS (BDA)
IMPLEMENTATION/CODING
BEHAVIOUR DRIVEN PROGRAMMING (BDP)
BEHAVIOUR DRIVEN SPECIFICATION (BDS)
=
ATDD
=
TDD

10. WHAT’S REALLY BDD?
SPECIFICATION/ANALYSIS
Feature: 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
Executable Specification
BUSSINESS VOCABULARY

11. WHAT’S REALLY BDD?
IMPLEMENTATION/CODING
Automated Debugging
Continuous Refactoring
public class SmartDateParserBehaviours {
@Test
public void should_parse_short_format(String birthday) {
// TODO
}
IMPLEMENTATION
}
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);
})
})
})
VOCABULARY

12. HAVE BDD CHANGED THE RULES FOR PROGRAMMERS?
We still continue coding with TDD rules
At the implementation level
BDD is just TDD using the proper words
SPECIFICATION (BDA)
IMPLEMENTATION (BDP)

13. WHAT’S TDD?

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

15. WHAT’S TDD?
AUTOMATED DEBUGGING

16. WHAT’S TDD?
AUTOMATED DEBUGGING

17. 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

18. WHAT’S TDD?
Test Driven Development
=
Test First Development
+
Refactoring

19. 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)

20. REFACTOR IS THE UNQUESTIONABLE STAR OF THE PICTURE
CONTINUOUS REFACTORING
If you are not refactoring in every iteration
you are not doing TDD
It is in the soul of Extreme Programming and Agile
YAGNI - Your ain’t gonna need it
Rapid Feedback
Embrace the change
First make it work, then make it right,
then make it small and fast

21. REFACTOR IS THE UNQUESTIONABLE STAR OF THE PICTURE
PROGRAMMERS MUST WORK WITH
BEHAVIOUR DRIVEN REFACTORING
DEATH OF THE TECHNICAL DEBT

22. BUT WHAT TEST DO I HAVE TO CODE?
SCOPE
SYSTEM TESTS
INTEGRATION TESTS
PURPOSE
ACCEPTANCE TESTS
FUNCTIONAL TESTS
UNIT TESTS
NON FUNCTIONAL TESTS
PERFORMANCE
VISIBILITY
WHITE BOX TESTS
BLACK BOX TESTS
LOAD
STRESS
...
USER INTERFACE TESTS

23. BUT WHAT TEST DO I HAVE TO CODE?
Acceptance
Tests
Unit Tests
Unit Tests
Integration
Tests
System
Tests
UI
Tests
Integration
Tests

24. 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”

25. F.I.R.S.T
FAST
INDEPENDENT
REPEATABLE
SMALL
TRANSPARENT

26. 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.

27. HOW MUCH TESTING?
THE TRADITIONAL TESTING PYRAMID
SYSTEM, UI, ACCEPTANCE
TESTS
INTEGRATION
TESTS
UNIT
TESTS

28. HOW MUCH TESTING?
MIKE COHN’S TESTING PYRAMID
UI
TESTS
ACCEPTANCE
TESTS
UNIT TESTS
Small in number
At least one per story
Loads of them
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.
* http://blog.mountaingoatsoftware.com/the-forgotten-layer-of-the-test-automation-pyramid/

29. WATCHING THE COVERAGE
WATCH 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

30. REFACTORING

31. 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.

32. 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

33. REFACTORING
UNIT TESTS MUST BE REFACTORED, TOO
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.
“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.”
Robert C. Martin (aka. Uncle Bob)
http://blog.8thlight.com/uncle-bob/2013/09/23/Test-first.html

34. TO MOCK OR NOT TO MOCK

35. 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.

36. COLLABORATION TESTS AND CONTRACT TESTS
10 TESTS
15 TESTS
DO WE HAVE TO TESTS ALL POSSIBLE PATHS?



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.

37. COLLABORATION TESTS AND CONTRACT TESTS
10 TESTS
15 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.

38. COLLABORATION TESTS AND CONTRACT TESTS
INTEGRATED TESTS ARE SCAM SERIES
J. B. Rainsberger (aka JBrains)
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

39. Would you like to know more?
Look for a good TDD course, go to a Coding
Dojo and do a lot of Code Katas.
Pedro Ballesteros
@pmbah