Getting out of Legacy with 3P (Protect-Prepare-Produce) - TechExcellence meetup

See the presentation : https://www.youtube.com/watch?v=E2d2BYxOiME

Summary
When you write tests or refactor at the end of a story, or worse in a separate story, who gets the benefits? And when?

Unfortunately it's the next person who touches the code ... sometime in the future ... if we're lucky. Given that the tests remain relevant. And given that the refactoring actually helps with the new functionality, that we don't know yet ... 🤔

That means our efforts in refactoring and tests are primarily for other people, sometime in the future and of uncertain value to them. Is it surprising if we don't do much of it and let the code rot?

An alternative, that maximizes the ROI of the tests and the refactoring, would be the Protect-Prepare-Produce method 🧐.

Protect
Write quick and dirty(!) tests to protect refactoring in the next step. Beware this can hurt some sensitive viewers.

Prepare
Refactor in depth to make the new functionality easier. Also make the code testable and improve the tests written in the previous step.

Produce
Code the new functionality in TDD. Should be a piece of cake given the Prepare phase.

Being the primary beneficiaries of the testing and refactoring we do ourselves means more happiness. With a much better ROI on testing and refactoring, we're likely to have a lot more of it.

Let's make this clear with a few examples. Not the least what I mean by QUICK and DIRTY tests.

ABOUT JOHAN

Johan Martinsson is a freelance dev coach, passionate about code and software design.

A serial kata-creator and co-creator of conferences SnowCamp and AlpesCraft, facilitator of regular meetups since 2009, he often finds (good) excuses for showing code at conferences.

LinkedIn: https://www.linkedin.com/in/jomartinsson/
Twitter: https://twitter.com/johan_alps
GitHub: https://github.com/martinsson
Blog: http://martinsson-johan.blogspot.com

Transcript

1. 3P PROTECT - PREPARE - PRODUCE Johan MARTINSSON
2. PROTECT PREPARE PRODUCE 3P PROTECT - PREPARE - PRODUCE Johan MARTINSSON
3. @Johan_alps
4. @Johan_alps
5. @Johan_alps
7. The more of the Just In Time, the better the state of the project
8. 3P
9. 3P PROTECT PREPARE PRODUCE
10. Ex 1: Receipt printer We want a html receipt and we already have text and csv Total price and VAT calculus is mixed with formatting String makeReceipt(productNames, catalog, receiptType) productNames, catalog, receiptType makeReceipt() text csv Photo by Michael Walter on Unsplash
11. Protect Just call the function Approval tests to assert the full text String result = receiptService.makeReceipt(panier, catalog, new TextPrinter()); Approvals.verify(result);
12. Protect Just call the function Approval tests to assert the full text String result = receiptService.makeReceipt(panier, catalog, new TextPrinter()); String expectedOutput = " JP Gothié créations, Paris \n" + "-----------------------\n" + " chemise deluxe 199.99 €\n" + " veste frimeur 520.50 €\n" + " chaussures cuir croco® 410.00 €\n" + "\n" + "Total: 1035.92 TTC\n" + "TVA: 172.65 \n" + "-----------------------\n" + " JP Gothié vous remercie pour votre visite"; assertThat(result).isEqualTo(expectedOutput);
13. Prepare Extract the calculations (total + vat) Normal assertions for the total and VAT Keep one approval test for csv, one for text
14. Produce TDD the html receipt, or ITL using approval tests
15. Approval testing • Automated assertion on strings (and bitmaps, …) • External di ff -tools to inspect di ff erences • convert complex data to strings or json • Scrubbers to normalize dates, uuids, etc String result = receiptService.makeReceipt(panier, catalog, new TextPrinter()); Approvals.verify(result);
16. Approval testing • Automated assertion on strings (and bitmaps, …) • External di ff -tools to inspect di ff erences • convert complex data to strings or json • Scrubbers to normalize dates, uuids, etc
17. Value of Information Expected gain: Probability * Value - Cost of doing
18. Value of Information 50 % chance of 1000 in value. Cost is 200
 50% * (1000 - 200) + 50% * (0-200) = 300 Expected gain: Probability * Value - Cost of doing
19. Value of Information 50 % chance of 1000 in value. Cost is 200
 50% * (1000 - 200) + 50% * (0-200) = 300 If you pay 50 to know : - 50 50% * (1000 - 200) + 50% * (0 - 0) = 350 Expected gain: Probability * Value - Cost of doing
20. Value of Information 50 % chance of 1000 in value. Cost is 200
 50% * (1000 - 200) + 50% * (0-200) = 300 If you pay 50 to know : - 50 50% * (1000 - 200) + 50% * (0 - 0) = 350 Expected gain: Probability * Value - Cost of doing 70 % chance of 1000 in value, 30% 2000 in penalty. Cost is still 200 70% * (1000-200) + 30% * (-2000-200) = 100
21. Value of Information 50 % chance of 1000 in value. Cost is 200
 50% * (1000 - 200) + 50% * (0-200) = 300 If you pay 50 to know : - 50 50% * (1000 - 200) + 50% * (0 - 0) = 350 Expected gain: Probability * Value - Cost of doing 70 % chance of 1000 in value, 30% 2000 in penalty. Cost is still 200 70% * (1000-200) + 30% * (-2000-200) = 100 If you pay 50 to know : - 50 70% * (1000-200) + 30% * (- 0 - 0) = 510
22. Value of Information Expected gain: Probability * Value - Cost of doing -250 -125 0 125 250 375 500 Useful Not useful Useful Not useful 300 350 Paying to know Paying to know 510
23. Value of Information Expected gain: Probability * Value - Cost of doing -250 -125 0 125 250 375 500 Useful Not useful Useful Not useful 300 350 Paying to know Paying to know 510
24. Value of Information Expected gain: Probability * Value - Cost of doing -250 -125 0 125 250 375 500 Useful Not useful Useful Not useful -700 -525 -350 -175 0 175 350 525 700 Useful Not useful Useful Not useful 300 350 Paying to know Paying to know 100 510
25. Value of Information Expected gain: Probability * Value - Cost of doing -250 -125 0 125 250 375 500 Useful Not useful Useful Not useful -700 -525 -350 -175 0 175 350 525 700 Useful Not useful Useful Not useful 300 350 Paying to know Paying to know 100 510
26. Cheap way of knowing?
27. Cheap way of knowing? Wait
28. Types of refactorings Simpli fi cation Reduce illegal states Encode knowledge Make extensible (apply OCP)
29. Types of refactorings Simpli fi cation Reduce illegal states Encode knowledge Make extensible (apply OCP) Which are good After?
30. Types of refactorings Simpli fi cation Reduce illegal states Encode knowledge Make extensible (apply OCP) Which are good After?
31. Types of refactorings Simpli fi cation Reduce illegal states Encode knowledge Make extensible (apply OCP) Which are good After?
32. Types of refactorings Simpli fi cation Reduce illegal states Encode knowledge Make extensible (apply OCP) Which are good After?
33. Types of refactorings Simpli fi cation Reduce illegal states Encode knowledge Make extensible (apply OCP) Which are good After?
34. @Johan_alps Test at end of story
35. @Johan_alps Test at start of story
36. Ef fi ciency? Test at start of story Test at end of story
37. Ef fi ciency? Test at start of story Test at end of story Replace with "micro increment” => TDD
38. Ef fi ciency? Test at start of story Test at end of story Replace with "micro increment” => TDD
39. Ef fi ciency? Learning? Test at start of story Test at end of story Replace with "micro increment” => TDD
40. Do the tests help? When we refactor? When we add new features? Learning
41. 3P PROTECT PREPARE PRODUCE
42. Ex 2: Lift pass pricing (kata) github.com/martinsson/Refactoring-Kata-Lift-Pass-Pricing
43. Ex 2: Lift pass pricing (kata) github.com/martinsson/Refactoring-Kata-Lift-Pass-Pricing We want a rest-route that calculates price of several lift-passes We’ve got one for a single lift-pass!
44. @Johan_alps Rest-mapping DB request Sending response anonymous function
45. @Johan_alps ing st anon
46. @Johan_alps onse
47. Protect Provide a database Hit the REST-API Assert the results
48. Prepare Extract the unit-cost function Adapt tests to the testable interfaces
49. @Johan_alps prices (rest) http domain infra
50. @Johan_alps GetPriceUsecase PriceDao Price prices (rest) http domain infra
51. @Johan_alps GetPriceUsecase PriceDao Price prices (rest) http domain infra
52. Produce TDD a new multiple-pass cost function and wrap it in a rest-route
53. ONE GOAL : MAKE IT SAFE TO REFACTOR - COVER ALL CASES - CAPTURE ALL BEHAVIOUR 3 P PROTECT
54. ONE GOAL : MAKE IT SAFE TO REFACTOR - COVER ALL CASES - CAPTURE ALL BEHAVIOUR 3 P PROTECT POSSIBLE COMPROMISES - STABILITY - ISOLATION - WORKS ON MY MACHINE - READABILITY ! - …
55. Quick and dirty tests FTW 💩
56. Refactoring tests To protect a refactoring: what do we care about? Test quality Importance Coverage Vital Captures all side-e ff ects Vital Sub-second Nice to have Stability (not fl aky) Nice to have Stability (regarding external data changes) Nice to have Readability Who cares Runs on any machine (CI) Wildly useless Allows new features Wildly useless
57. Types of tests and qualities
58. Types of tests and qualities Nice place
59. Types of tests and qualities Nice place Nice place
60. Types of tests and qualities Nice place Nice place
61. Types of tests and qualities Nice place Nice place
62. PREPARATORY REFACTORING 3 P PREPARE
63. PREPARATORY REFACTORING MAKE IT "UNIT" TESTABLE 3 P PREPARE
64. PREPARATORY REFACTORING MAKE IT "UNIT" TESTABLE => OFTEN SIMILAR 3 P PREPARE
65. PREPARATORY REFACTORING MAKE IT "UNIT" TESTABLE => OFTEN SIMILAR 3 P PREPARE
66. PREPARATORY REFACTORING MAKE IT "UNIT" TESTABLE => OFTEN SIMILAR 3 P PREPARE
67. JUST IMPLEMENT USING TDD… … NO MATTER THE ORIGINAL CODE 3 P PRODUCE
68. Diff - trackers A multi-stage processing accumulates multiple mongodb queries that are executed at the end We want to change the request that is made Pb : unit testing the syntax of mongodb ? •Brittle •TDD for new features would be ridiculous shopping_cart_tracker.update({ "$set": { “ware_house”: warehouse_id, “stock_status": VERIFIED, } })
69. Diff - trackers A multi-stage processing accumulates multiple mongodb queries that are executed at the end We want to change the request that is made Pb : unit testing the syntax of mongodb ? •Brittle •TDD for new features would be ridiculous shopping_cart_tracker.update({ "$set": { “ware_house”: warehouse_id, “stock_status": VERIFIED, } }) shopping_cart_events.add_event( StockVerified(warehouse_id) )
70. Protect Start mongodb locally Insert data for testing Assert side-e ff ects by reading from db
71. Prepare Replace with Domain Events Separate code into 1. Loading 2. Computation of desired state 3. Saving Isolate tests - most tests concern computation
72. Produce TDD the new behaviour,
 simply emitting new Events 
 and calculating desired state
73. WireMock • stubs: somewhat useful for changing data or costly requests • veri fi cation: assertions on fi re-and-forget side e ff ects. Also useful for not damaging data
74. Test transition PROTECT PREPARE PRODUCE
75. Work fl ow comparison 3P TEST LAST IMPRESSION OF MAKING PROGRESS MAKING PROGRESS IMPRESSION OF NO PROGRESS
76. @Johan_alps From : CodeScene
77. @Johan_alps From : CodeScene
78. @Johan_alps From : CodeScene
79. @Johan_alps From : CodeScene A fraction of the e ff ort
80. When to 3P ? • We want to improve the code, but tests are lacking • We want something progressive • The code is the only spec • We don’t want bugs It maximises ROI, in a progressive fashion, associating it with stories. So
81. When not to 3P ? • When it is convenient to replace with new code • Possibly when specs are Known • We can TDD a replacement (only it’s not progressive) • When the project has no (little) ambition • Not every improvement can be linked to a story
82. Smaller is more
83. The mikado method
84. Better ROI => more of it Test and refactoring JIT => better ROI Decide late 3P allows for massive, incremental refactoring 3P enables TDD in any project 3P is safe (but maybe not SAFe) Adopting TDD? => Feedback on viability in days Smaller batches Recap Photo by Steven Wright on Unsplash
85. 3P
86. 3P https://martinsson-johan.blogspot.com/ 2022/11/breaking-out-of-legacy-with-3p.html