Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Refactoring legacy code driven by tests
Luca Minudel + Saleem Siddiqui
I’m the
Refactoring
Chicken
I’m the
TDD egg
Let’s clarify the scope of this Workshop
Languages supported in this Workshop
C#
Java
JavaScript
Ruby
Python
Automatic Testing Continuum
Specification
(documentation)
DesignVerification
Scope of this workshop
Specification
(documentation)
DesignVerification
Types of Automatic Tests
End-to-end, out-of-process, business facing
Unit, in-process, technology facing
Scope of this workshop
End-to-end, out-of-process, business facing
Unit, in-process, technology facing
Exercise 1: Tire Pressure Monitoring System
Alarm class:
monitors tire pressure and sets an alarm if the pressure falls
ou...
Exercise 1: Tire Pressure Monitoring System
Alarm class:
monitors tire pressure and sets an alarm if the pressure falls
ou...
Exercise 1: Tire Pressure Monitoring System
Write the unit tests for the Alarm class.
Refactor the code as much as you nee...
Exercise 1: Tire Pressure Monitoring System
Write the unit tests for the Alarm class.
Refactor the code as much as you nee...
Exercise 1: Tire Pressure Monitoring System
Write the unit tests for the Alarm class.
Refactor the code as much as you nee...
The SOLID acronym
S single responsibility principle
O open closed principle
L Liskov substitution principle
I interface se...
Dependency Inversion Principle (DIP)
Martin Fowler's definition:
a) High level modules should not depend upon
low level mo...
Dependency Inversion Principle (DIP)
Both low level classes and high level classes
should depend on abstractions.
High lev...
DIP Violation In Example Code
High Level Class
Low Level Class
Dependency
Open Closed Principle (OCP)
Bertrand Meyer's definition:
Software entities (classes, modules, functions,
etc.) should be o...
Open Closed Principle (OCP)
Classes and methods should be
open for extensions
&
strategically closed for modification.
So ...
OCP Violation In Example Code
Want to use a new type of sensor?
Must modify code; cannot extend it
Reference: WELC
Parametrize Constructor
Extract Interface
Exercise 2: Unicode File To Htm Text Converter
UnicodeFileToHtmTextConverter class:
formats a plain text file for display ...
Exercise 2: Unicode File To Htm Text Converter
Write the unit tests for the UnicodeFileToHtmTextConverter
class.
Refactor ...
Exercise 2: Unicode File To Htm Text Converter
Write the unit tests for the UnicodeFileToHtmTextConverter
class.
Refactor ...
Exercise 2: Unicode File To Htm Text Converter
Write the unit tests for the UnicodeFileToHtmTextConverter
class.
Refactor ...
Feathers’ rules of thumb. Extended !
A test is not a unit test when:
 It talks to the database
 It communicates across t...
Mike Cohn's Test Pyramid. Explained !
UI
tests
Integration
tests
Unit tests
Reference: WELC
Parametrize Constructor
Extract Interface
Skin and Wrap the API
Refactoring and TDD
Should we inject this dependency?
Behavior of TextReader
TextReader documentation from MSDN
Non-idempotent behavior
Dependency injection and
idempotent behavior
Refactoring and TDD
Exercise 3: Ticket Dispenser
TicketDispenser class:
manages a queuing system in a shop.
There may be more than one ticket ...
Exercise 3: Ticket Dispenser
TurnTicket class:
represent the ticket with the turn number.
TurnNumberSequence class:
return...
Write the unit tests for the TicketDispenser class.
Refactor the code as much as you need to make the
TicketDispenser clas...
Write the unit tests for the TicketDispenser class.
Refactor the code as much as you need to make the
TicketDispenser clas...
Write the unit tests for the TicketDispenser class.
Refactor the code as much as you need to make the
TicketDispenser clas...
Reference: WELC
Parametrize Constructor
Extract Interface
Skin and Wrap the API
Introduce Instance Delegator
…
Exercise 4: Telemetry System
TelemetryDiagnosticControl class:
establishes a connection to the telemetry server through th...
Write the unit tests for the TelemetryDiagnosticControl class.
Refactor the code as much as you need to make the class
tes...
Write the unit tests for the TelemetryDiagnosticControl class.
Refactor the code as much as you need to make the class
tes...
Write the unit tests for the TelemetryDiagnosticControl class.
Refactor the code as much as you need to make the class
tes...
Single Responsibility Principle (SRP)
A class should have only one reason to change.
Single Responsibility Principle (SRP)
There should never be more than one reason for
a class to change.
A class should hav...
Interface Segregation Principle (IRP)
Clients should not be forced to depend upon
interfaces that they do not use.
Interface Segregation Principle (IRP)
Clients should not be forced to depend upon
interface members that they don't use.
I...
Reference: SRP
http://www.objectmentor.com/resources/articles/srp.pdf
Pag. 151/152
Synergy between testing and design
Michael Feathers:
writing tests is another way to look the code and
locally understand ...
More references
More references
More references
References
 http://scratch.mit.edu/projects/13134082/
 http://vimeo.com/15007792
 http://martinfowler.com/bliki/TestPyr...
References / Links / Slides
On Twitter
On Twitter :
@S2IL
@LUKADOTNET
Upcoming SlideShare
Loading in …5
×

of

Refactoring legacy code driven by tests - ENG Slide 1 Refactoring legacy code driven by tests - ENG Slide 2 Refactoring legacy code driven by tests - ENG Slide 3 Refactoring legacy code driven by tests - ENG Slide 4 Refactoring legacy code driven by tests - ENG Slide 5 Refactoring legacy code driven by tests - ENG Slide 6 Refactoring legacy code driven by tests - ENG Slide 7 Refactoring legacy code driven by tests - ENG Slide 8 Refactoring legacy code driven by tests - ENG Slide 9 Refactoring legacy code driven by tests - ENG Slide 10 Refactoring legacy code driven by tests - ENG Slide 11 Refactoring legacy code driven by tests - ENG Slide 12 Refactoring legacy code driven by tests - ENG Slide 13 Refactoring legacy code driven by tests - ENG Slide 14 Refactoring legacy code driven by tests - ENG Slide 15 Refactoring legacy code driven by tests - ENG Slide 16 Refactoring legacy code driven by tests - ENG Slide 17 Refactoring legacy code driven by tests - ENG Slide 18 Refactoring legacy code driven by tests - ENG Slide 19 Refactoring legacy code driven by tests - ENG Slide 20 Refactoring legacy code driven by tests - ENG Slide 21 Refactoring legacy code driven by tests - ENG Slide 22 Refactoring legacy code driven by tests - ENG Slide 23 Refactoring legacy code driven by tests - ENG Slide 24 Refactoring legacy code driven by tests - ENG Slide 25 Refactoring legacy code driven by tests - ENG Slide 26 Refactoring legacy code driven by tests - ENG Slide 27 Refactoring legacy code driven by tests - ENG Slide 28 Refactoring legacy code driven by tests - ENG Slide 29 Refactoring legacy code driven by tests - ENG Slide 30 Refactoring legacy code driven by tests - ENG Slide 31 Refactoring legacy code driven by tests - ENG Slide 32 Refactoring legacy code driven by tests - ENG Slide 33 Refactoring legacy code driven by tests - ENG Slide 34 Refactoring legacy code driven by tests - ENG Slide 35 Refactoring legacy code driven by tests - ENG Slide 36 Refactoring legacy code driven by tests - ENG Slide 37 Refactoring legacy code driven by tests - ENG Slide 38 Refactoring legacy code driven by tests - ENG Slide 39 Refactoring legacy code driven by tests - ENG Slide 40 Refactoring legacy code driven by tests - ENG Slide 41 Refactoring legacy code driven by tests - ENG Slide 42 Refactoring legacy code driven by tests - ENG Slide 43 Refactoring legacy code driven by tests - ENG Slide 44 Refactoring legacy code driven by tests - ENG Slide 45 Refactoring legacy code driven by tests - ENG Slide 46 Refactoring legacy code driven by tests - ENG Slide 47 Refactoring legacy code driven by tests - ENG Slide 48 Refactoring legacy code driven by tests - ENG Slide 49 Refactoring legacy code driven by tests - ENG Slide 50 Refactoring legacy code driven by tests - ENG Slide 51 Refactoring legacy code driven by tests - ENG Slide 52
Upcoming SlideShare
Architettura del software un approccio Agile, Web-cast Microsoft 2006
Next
Download to read offline and view in fullscreen.

12 Likes

Share

Download to read offline

Refactoring legacy code driven by tests - ENG

Download to read offline

re you working on code poorly designed or on legacy code that’s hard to test? And you cannot refactor it because there are no tests?

During this Coding Dojo you’ll be assigned a coding challenge in Java, C#, Ruby, JavaScript or Python. You will face the challenge of improving the design and refactoring existing code in order to make it testable and to write unit tests.

We will discuss SOLID principles, the relation between design and TDD, and how this applies to your solution.

Reading list:
Growing Object-Oriented Software, Guided by Tests; Steve Freeman, Nat Pryce
Test Driven Development: By Example; Kent Beck
Working Effectively with Legacy; Michael Feathers
Agile Software Development, Principles, Patterns, and Practices; Robert C. Martin (C++, Java)
Agile Principles, Patterns, and Practices in C#; Robert C. Martin (C#)

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Refactoring legacy code driven by tests - ENG

  1. 1. Refactoring legacy code driven by tests Luca Minudel + Saleem Siddiqui I’m the Refactoring Chicken I’m the TDD egg
  2. 2. Let’s clarify the scope of this Workshop
  3. 3. Languages supported in this Workshop C# Java JavaScript Ruby Python
  4. 4. Automatic Testing Continuum Specification (documentation) DesignVerification
  5. 5. Scope of this workshop Specification (documentation) DesignVerification
  6. 6. Types of Automatic Tests End-to-end, out-of-process, business facing Unit, in-process, technology facing
  7. 7. Scope of this workshop End-to-end, out-of-process, business facing Unit, in-process, technology facing
  8. 8. Exercise 1: Tire Pressure Monitoring System Alarm class: monitors tire pressure and sets an alarm if the pressure falls outside of the expected range.
  9. 9. Exercise 1: Tire Pressure Monitoring System Alarm class: monitors tire pressure and sets an alarm if the pressure falls outside of the expected range. Sensor class: simulates the behavior of a real tire sensor, providing random but realistic values.
  10. 10. Exercise 1: Tire Pressure Monitoring System Write the unit tests for the Alarm class. Refactor the code as much as you need to make the Alarm class testable.
  11. 11. Exercise 1: Tire Pressure Monitoring System Write the unit tests for the Alarm class. Refactor the code as much as you need to make the Alarm class testable. Minimize changes to the public API as much as you can.
  12. 12. Exercise 1: Tire Pressure Monitoring System Write the unit tests for the Alarm class. Refactor the code as much as you need to make the Alarm class testable. Minimize changes to the public API as much as you can. Extra credits: Alarm class fails to follow one or more of the SOLID principles. Write down the line number, the principle & the violation.
  13. 13. The SOLID acronym S single responsibility principle O open closed principle L Liskov substitution principle I interface segregation principle D dependency inversion principle
  14. 14. Dependency Inversion Principle (DIP) Martin Fowler's definition: a) High level modules should not depend upon low level modules, both should depend upon abstractions. b) Abstractions should not depend upon details, details should depend upon abstractions.
  15. 15. Dependency Inversion Principle (DIP) Both low level classes and high level classes should depend on abstractions. High level classes should not depend on low level classes.
  16. 16. DIP Violation In Example Code High Level Class Low Level Class Dependency
  17. 17. Open Closed Principle (OCP) Bertrand Meyer's definition: Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
  18. 18. Open Closed Principle (OCP) Classes and methods should be open for extensions & strategically closed for modification. So that the behavior can be changed and extended adding new code instead of changing the class.
  19. 19. OCP Violation In Example Code Want to use a new type of sensor? Must modify code; cannot extend it
  20. 20. Reference: WELC Parametrize Constructor Extract Interface
  21. 21. Exercise 2: Unicode File To Htm Text Converter UnicodeFileToHtmTextConverter class: formats a plain text file for display in a browser.
  22. 22. Exercise 2: Unicode File To Htm Text Converter Write the unit tests for the UnicodeFileToHtmTextConverter class. Refactor the code as much as you need to make the class testable.
  23. 23. Exercise 2: Unicode File To Htm Text Converter Write the unit tests for the UnicodeFileToHtmTextConverter class. Refactor the code as much as you need to make the class testable. Minimize changes to the public API as much as you can.
  24. 24. Exercise 2: Unicode File To Htm Text Converter Write the unit tests for the UnicodeFileToHtmTextConverter class. Refactor the code as much as you need to make the class testable. Minimize changes to the public API as much as you can. Extra credits: UnicodeFileToHtmTextConverter class fails to follow one or more of the SOLID principles. Write down the line number, the principle & the violation.
  25. 25. Feathers’ rules of thumb. Extended ! A test is not a unit test when:  It talks to the database  It communicates across the network  It touches the file system or reads config info  It uses DateTime.now() or Random  It depends on non-deterministic behavior  It can't run at the same time as any of your other unit tests  You have to do special things to your environment (such as editing config files) to run it.
  26. 26. Mike Cohn's Test Pyramid. Explained ! UI tests Integration tests Unit tests
  27. 27. Reference: WELC Parametrize Constructor Extract Interface Skin and Wrap the API
  28. 28. Refactoring and TDD Should we inject this dependency?
  29. 29. Behavior of TextReader TextReader documentation from MSDN Non-idempotent behavior
  30. 30. Dependency injection and idempotent behavior
  31. 31. Refactoring and TDD
  32. 32. Exercise 3: Ticket Dispenser TicketDispenser class: manages a queuing system in a shop. There may be more than one ticket dispenser but the same ticket should not be issued to two different customers.
  33. 33. Exercise 3: Ticket Dispenser TurnTicket class: represent the ticket with the turn number. TurnNumberSequence class: returns the sequence of turn numbers.
  34. 34. Write the unit tests for the TicketDispenser class. Refactor the code as much as you need to make the TicketDispenser class testable. Exercise 3: Ticket Dispenser
  35. 35. Write the unit tests for the TicketDispenser class. Refactor the code as much as you need to make the TicketDispenser class testable. Minimize changes to the public API as much as you can. Exercise 3: Ticket Dispenser
  36. 36. Write the unit tests for the TicketDispenser class. Refactor the code as much as you need to make the TicketDispenser class testable. Minimize changes to the public API as much as you can. Extra credits: TicketDispenser class fails to follow one or more of the OO and SOLID principles. Write down the line number, the principle & the violation. Exercise 3: Ticket Dispenser
  37. 37. Reference: WELC Parametrize Constructor Extract Interface Skin and Wrap the API Introduce Instance Delegator …
  38. 38. Exercise 4: Telemetry System TelemetryDiagnosticControl class: establishes a connection to the telemetry server through the TelemetryClient, sends a diagnostic request and receives the response with diagnostic info. TelemetryClient class: simulates the communication with the Telemetry Server, sends requests and then receives and returns the responses
  39. 39. Write the unit tests for the TelemetryDiagnosticControl class. Refactor the code as much as you need to make the class testable. Exercise 4: Telemetry System
  40. 40. Write the unit tests for the TelemetryDiagnosticControl class. Refactor the code as much as you need to make the class testable. Minimize changes to the public API as much as you can. Exercise 4: Telemetry System
  41. 41. Write the unit tests for the TelemetryDiagnosticControl class. Refactor the code as much as you need to make the class testable. Minimize changes to the public API as much as you can. Extra credits: TelemetryClient class fails to follow one or more of the OO and SOLID principles. Write down the line number, the principle & the violation. Exercise 4: Telemetry System
  42. 42. Single Responsibility Principle (SRP) A class should have only one reason to change.
  43. 43. Single Responsibility Principle (SRP) There should never be more than one reason for a class to change. A class should have one and only one responsibility.
  44. 44. Interface Segregation Principle (IRP) Clients should not be forced to depend upon interfaces that they do not use.
  45. 45. Interface Segregation Principle (IRP) Clients should not be forced to depend upon interface members that they don't use. Interfaces that serve only one scope should be preferred over fat interfaces.
  46. 46. Reference: SRP http://www.objectmentor.com/resources/articles/srp.pdf Pag. 151/152
  47. 47. Synergy between testing and design Michael Feathers: writing tests is another way to look the code and locally understand it and reuse it, and that is the same goal of good OO design. This is the reason for the deep synergy between testability and good design.
  48. 48. More references
  49. 49. More references
  50. 50. More references
  51. 51. References  http://scratch.mit.edu/projects/13134082/  http://vimeo.com/15007792  http://martinfowler.com/bliki/TestPyramid.html  http://martinfowler.com/bliki/StranglerApplication.html  http://www.markhneedham.com/blog/2009/07/07/domain- driven-design-anti-corruption-layer/  http://www.objectmentor.com/resources/articles/srp.pdf  http://www.objectmentor.com/resources/articles/ocp.pdf  http://www.objectmentor.com/resources/articles/lsp.pdf  http://www.objectmentor.com/resources/articles/isp.pdf  http://www.objectmentor.com/resources/articles/dip.pdf
  52. 52. References / Links / Slides On Twitter On Twitter : @S2IL @LUKADOTNET
  • medeaeva

    May. 21, 2019
  • zahernourredine

    Dec. 6, 2018
  • TilmanMoser

    Feb. 28, 2018
  • eldhoabe

    Jan. 4, 2017
  • JosefScherer

    Sep. 1, 2016
  • cristinacarstea

    Jan. 15, 2016
  • merezano

    Dec. 3, 2015
  • powerirs

    Jul. 5, 2015
  • PoShengHsu

    Apr. 25, 2015
  • kvinayaks1

    Apr. 12, 2015
  • johan.moreau

    Dec. 19, 2014
  • skarasif

    Nov. 18, 2014

re you working on code poorly designed or on legacy code that’s hard to test? And you cannot refactor it because there are no tests? During this Coding Dojo you’ll be assigned a coding challenge in Java, C#, Ruby, JavaScript or Python. You will face the challenge of improving the design and refactoring existing code in order to make it testable and to write unit tests. We will discuss SOLID principles, the relation between design and TDD, and how this applies to your solution. Reading list: Growing Object-Oriented Software, Guided by Tests; Steve Freeman, Nat Pryce Test Driven Development: By Example; Kent Beck Working Effectively with Legacy; Michael Feathers Agile Software Development, Principles, Patterns, and Practices; Robert C. Martin (C++, Java) Agile Principles, Patterns, and Practices in C#; Robert C. Martin (C#)

Views

Total views

2,264

On Slideshare

0

From embeds

0

Number of embeds

9

Actions

Downloads

61

Shares

0

Comments

0

Likes

12

×