A presentation at That Conference in August 2013 in Wisconsin Dells, WI, USA by Jenna Pederson
@JENNAPEDERSON W W W. 6 1 2 S O F T W A R E F O U N D R Y. C O M L E AV E N O T R A C E : TEST DRIVEN DEVELOPMENT USING THE SOLID PRINCIPLES COPYRIGHT © 2014 JENNA PEDERSON. ALL RIGHTS RESERVED.
WHO AM I? • Independent, full-stack web developer • Code geek + process geek - agile, TDD, productivity, etc. • Co-Ambassador for the Twin Cities Geekettes • www.geekettes.io • @jennapederson • www.612softwarefoundry.com
AGENDA • What makes a design good? • Test Driven Development • SOLID Principles • Examples
W H AT M A K E S A D E S I G N G O O D ?
I T I S H A R D T O C H A N G E B E C A U S E E V E R Y C H A N G E A F F E C T S T O O M A N Y O T H E R PA R T S OF THE SYSTEM. RIGIDITY
W H E N Y O U M A K E A C H A N G E , U N E X P E C T E D PA R T S O F T H E S Y S T E M B R E A K . FRAGILITY
I T I S H A R D T O R E U S E I N A N O T H E R A P P L I C AT I O N B E C A U S E I T C A N N O T B E D I S E N TA N G L E D F R O M T H E C U R R E N T A P P L I C AT I O N . IMMOBILITY
MAKE IT WORK, MAKE IT BETTER W H AT I S T D D ?
A C L A S S S H O U L D H A V E O N E A N D O N LY ONE REASON TO CHANGE. SINGLE RESPONSIBILITY PRINCIPLE
B ER FEOSRREP S R P BEFO
AFTER SRP
AFTER SRP
A P P LY I N G S R P T O O U R T E S T I N G • Tests are more granular • Easier to understand and maintain • Fewer changes to tests • Failing tests point to only one responsibility instead of many
YOU SHOULD BE ABLE TO EXTEND A CLASS’ B E H A V I O R , W I T H O U T M O D I F Y I N G I T. THE OPEN CLOSED PRINCIPLE
B ER FEOSRREP O C P BEFO
A FR TE ESRR O BEFO P CP
A P P LY I N G O C P T O O U R T E S T I N G • Classes under test are open so we can: • inject mocked dependencies • override methods that make calls to external services
DERIVED CLASSES MUST BE S U B S T I T U TA B L E F O R T H E I R B A S E C L A S S E S . LISKOV SUBSTITUTION PRINCIPLE
B ER FEOSRREP L S P BEFO
A FR TE ESRR LPS P BEFO
A P P LY I N G L S P T O O U R T E S T I N G • Allows us to mock dependencies by creating substitutes (derived classes or mocks) • Helps keep tests isolated so we only test one responsibility • Less coupling to dependencies means we don’t need to know as much about the internals to write a test
M A K E F I N D G R A I N E D I N T E R F A C E S T H AT ARE CLIENT SPECIFIC. I N T E R FA C E S E G R E G AT I O N PRINCIPLE
B ER FEOSRREP I S P BEFO
A FR TE ESRR IPS P BEFO
A P P LY I N G I S P T O O U R T E S T I N G • Classes depend on narrower interfaces, making • tests smaller • mocking easier
DEPEND ON ABSTRACTIONS, NOT ON CONCRETIONS. DEPENDENCY INVERSION PRINCIPLE
B ER FEOSRREP D I P BEFO
A FR TE ESRR D BEFO P IP
A P P LY I N G D I P T O O U R T E S T I N G • Writing more decoupled code allows mocking and injecting of dependencies • If you skip these abstractions, your tests become more end-to-end tests because you are unable to swap out implementations for mocks.
N O W W H AT ? • Use the SOLID Principles to guide your way toward keeping your codebase clean, easier to extend, maintain, and reuse • SOLID is not the law • TDD does not guarantee good design • Don’t forget to engage your brain!
QUESTIONS?
H T T P S : / / W W W. T H AT C O N F E R E N C E . C O M / SPONSORS PLEASE THANK THE SPONSORS!
HTTPS://GITHUB.COM/JENNAPEDERSON/TDD-USING-THE-SOLID-PRINCIPLES CODE & RESOURCES S O L I D M O T I V AT I O N A L P H O T O C R E D I T S : H T T P : / / B I T. LY / M O T I V AT I O N A L _ S O L I D
@JENNAPEDERSON W W W. 6 1 2 S O F T W A R E F O U N D R Y. C O M THANK YOU!
