Behaviour Driven Refactoring or I'm a programmer, what the hell do I have to test?

1,089 views

Published on

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?

Published in: Technology, Education
  • Be the first to comment

Behaviour Driven Refactoring or I'm a programmer, what the hell do I have to test?

  1. 1. BEHAVIOUR DRIVEN REFACTORING OR I AM A PROGRAMMER, WHAT THE HELL DO I HAVE TO TEST? Pedro Ballesteros @pmbah
  2. 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”?
  3. 3. WE’RE DOING BEHAVIOUR DRIVEN REFACTORING
  4. 4. WHAT’S REALLY BDD? HAVE BDD CHANGED THE RULES FOR PROGRAMMERS? WE CONTINUE USING TDD RULES BUT WITH OTHER WORDS
  5. 5. 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…
  6. 6. 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”
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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)
  11. 11. WHAT’S TDD?
  12. 12. WHAT’S TDD? Test Driven Development “mantra”: red - green - refactor
  13. 13. WHAT’S TDD? AUTOMATED DEBUGGING
  14. 14. WHAT’S TDD? AUTOMATED DEBUGGING
  15. 15. 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
  16. 16. WHAT’S TDD? Test Driven Development = Test First Development + Refactoring
  17. 17. 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)
  18. 18. 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
  19. 19. REFACTOR IS THE UNQUESTIONABLE STAR OF THE PICTURE PROGRAMMERS MUST WORK WITH BEHAVIOUR DRIVEN REFACTORING DEATH OF THE TECHNICAL DEBT
  20. 20. 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
  21. 21. BUT WHAT TEST DO I HAVE TO CODE? Acceptance Tests Unit Tests Unit Tests Integration Tests System Tests UI Tests Integration Tests
  22. 22. 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”
  23. 23. F.I.R.S.T FAST INDEPENDENT REPEATABLE SMALL TRANSPARENT
  24. 24. 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.
  25. 25. HOW MUCH TESTING? THE TRADITIONAL TESTING PYRAMID SYSTEM, UI, ACCEPTANCE TESTS INTEGRATION TESTS UNIT TESTS
  26. 26. 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/
  27. 27. 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
  28. 28. REFACTORING
  29. 29. 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.
  30. 30. 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
  31. 31. 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
  32. 32. TO MOCK OR NOT TO MOCK
  33. 33. 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.
  34. 34. 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.
  35. 35. 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.
  36. 36. 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
  37. 37. 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

×