Bye Bye Cowboy Coder Days! (Legacy Code & TDD)

download Bye Bye Cowboy Coder Days! (Legacy Code & TDD)

of 34

  • date post

    20-May-2015
  • Category

    Technology

  • view

    278
  • download

    2

Embed Size (px)

description

Bye Bye Cowboy-Coder days! by Vytautas Dagilis. „Working Effectively with Legacy Code“- one of the best books which talks about Unit testing and TDD. Presentation covers best practices listed in the book as well as shows which of them were successfully implemented in practice. You will find out how to commit changes and be sure that they work even without running and testing application itself.

Transcript of Bye Bye Cowboy Coder Days! (Legacy Code & TDD)

  • 1. Bye Bye Cowboy-Coderdays!

2. What do developers do for living?Change the code! 3. Four Reasons to Change Software Adding a feature Fixing a bug Improving the design Optimizing resource usage 4. Changing SoftwareAdding aFeatureFixing a Bug Refactoring OptimizingStructure Changes Changes ChangesNewChangesFunctionalityFunctionality ChangesResourceUsageChanges 5. Preserving behaviorExisting Behavior New Behavior 6. Risky Change1. What changes do we have to make?2. How will we know that we've done them correctly?3. How will we know that we haven't broken anything? 7. How? 8. Working with Feedback!Yes, Unit Tests 9. Few qualities of Unit Tests They run fast They help us localize problems 10. Dependencies No way to run separately Takes time to load Hard to localize problem 11. GUI TestsIntegrationTestsUnit Tests 12. GUI TestsIntegrationTestsUnit Tests 13. Lag TimeTime to fix/Price1 Minute 10 Minutes 1 Hour 1 Day 1 WeekTime to fix/Price 14. The Legacy Code DilemmaWhen we change code, we should have tests in place. To puttests in place, we often have to change code. 15. The Legacy Code Change Algorithm1. Identify change points2. Find test points3. Break dependencies4. Write tests5. Make changes and refactor 16. Sensing and Separation We break dependencies to sense when we can't accessvalues our code computes We break dependencies to separate when we can't even geta piece of code into a test harness to run 17. Faking Collaborators Fake Objects Mock Objects Nothing! 18. Sprout 19. Sprout Method1. Identify where to change2. Wdown a method call and then comment it out.3. Determine what local variables you need for the call4. Determine return value5. Develop the sprout method using test-driven development6. Remove the comment in the source method 20. Sprout Class1. Identify where you need to make your code change.2. Write class in that place, and call a method; thencomment those lines out3. Determine what local variables you need from the sourcemethod, and make them arguments to the classes'constructor4. Determine return values to the source method and add acall in the source method to receive those values.5. Develop the sprout class test first6. Remove the comment in the source 21. Wrap 22. Wrap Method1. Identify a method you need to change2. If the change can be formulated as a single sequence ofstatements in one place, develop a new method for itusing test-driven development3. Create another method that calls the new method and theold method 23. Wrap Class1. Identify a method where you need to make a change.2. Create a class that accepts the class you are going towrap as a constructor argument.3. Create a method on that class, using test-drivendevelopment.4. Write another method that calls the new method and theold method on the wrapped class5. Instantiate the wrapper class in your code in the placewhere you need to enable the new behavior 24. TDD and Legacy Code1. Get the class you want to change under test2. Write a failing test case3. Get it to compile4. Make it pass (Try not to change existing code as you dothis)5. Remove duplication6. Repeat 25. Allways check if tests are testing1. Write test and new code in separate changelist2. Shelve new code change list3. Ensure tests are failing 26. Characterization Tests1. Use a piece of code in a test harness2. Write an assertion that you know will fail - let thefailure tell you what the behavior is3. Change the test so that it expects the behavior thatthe code produces4. Repeat 27. I Can't Get This Class into a TestHarness Lean on the Compiler Extract Interface Extract Implementer Subclass and Override Method Parameterize Constructor Parameterize Method Extract and Override Getter Extract and Override Factory Method Singleton Design Pattern 28. When All Else Fails, Do Some ScratchRefactoring 29. Questions? 30. Agile Turas Lietuvoje Agile Tour Kaunas rugsjo 25 d. Agile Tour Vilnius spalio 9 d. Agile Master Classeswww.agileturas.lt 31. The Worlds Best Intro to TDD J. B. Rainsberger, Kanada 2 Dien mokymai, Kaune Rugsjo 23 - 24 d.www.agileturas.lt/master-classes