Upload
sudeepsk2001
View
222
Download
0
Embed Size (px)
Citation preview
8/3/2019 Whitepaper Building Test Ability Into Legacy Code Oct2010
1/12
W
HITE
P
APER
BuildingTestabilityinto
LegacyCode
Version1.0
October,2010
8/3/2019 Whitepaper Building Test Ability Into Legacy Code Oct2010
2/12
2
GettingreadyforPLM
CopyrightNotice
GeometricLimited.Allrightsreserved.
Nopartofthisdocument(whetherinhardcopyorelectronicform)maybereproduced,storedinaretrieva
system,ortransmitted, inanyformorbyanymeans,electronic,mechanical,photocopying,recording,o
otherwise, to any third party without the written permission of Geometric Limited. Geometric Limited
reservestherighttochangetheinformationcontainedinthisdocumentwithoutpriornotice.
The names or trademarks or registered trademarks used in this document are the sole property of the
respectiveownersandaregoverned/protectedbytherelevanttrademarkandcopyrightlaws.
ThisdocumentisprovidedbyGeometricLimitedforinformationalpurposesonly,withoutrepresentationo
warrantyofanykind,andGeometricLimitedshallnotbeliableforerrorsoromissionswithrespecttothe
document.The informationcontainedherein isprovidedonanASISbasisand tothemaximumexten
permittedbyapplicablelaw,GeometricLimitedherebydisclaimsallotherwarrantiesandconditions,eithe
express, implied or statutory, including but not limited to, any (if any) implied warranties, duties o
conditionsofmerchantability,offitnessforaparticularpurpose,ofaccuracyorcompletenessofresponses
of results, of workmanlike effort, of lack of viruses, and of lack of negligence, all with regard to the
document.
THEREISNOWARRANTYORCONDITIONOFNONINFRINGEMENTOFANYINTELLECTUALPROPERTYRIGHTS
WITH REGARD TO THE DOCUMENT. IN NO EVENT WILL GEOMETRIC LIMITED BE LIABLE TO ANY OTHER
PARTY FOR LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, DIRECT
INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE
ARISINGINANYWAYOUTOFTHISDOCUMENT,WHETHERORNOTSUCHPARTYHADADVANCENOTICEOF
THEPOSSIBILITYOFSUCHDAMAGES.
ConfidentialityNotice
Thisdocumentisdisclosedonlytotherecipientpursuanttoaconfidentialityrelationshipunderwhichthe
recipient has confidentiality obligations defined herein after. This document constitutes confidentia
informationandcontainsproprietaryinformationbelongingtoGeometricLimited,andtherecipient,byits
receiptofthisdocument,acknowledgesthesame.Therecipientshallusetheconfidentialinformationonly
for thepurposedefinedaboveforwhichthisdocument issupplied.TherecipientmustobtainGeometric
Limitedswrittenconsentbeforetherecipientdisclosesanyinformationonthecontentsorsubjectmatte
ofthisdocumentorpartthereoftoanythirdpartywhichmayincludeanindividual,firmorcompanyoran
employee or employees of such a firm or company. The recipient acknowledges its obligation to comply
withtheprovisionsofthisconfidentialitynotice.
8/3/2019 Whitepaper Building Test Ability Into Legacy Code Oct2010
3/12
3
GettingreadyforPLM
Contents
Introduction ............................................................................................................ 4
Background ............................................................................................................. 4
WhatisLegacyCode? ............................................................................................. 5
FundamentalChallengesinBuildingTestabilityintoLegacyCode ........................ 5
TheSeamConcept .................................................................................................. 6
FurtherChallengesinBuildingTestability .............................................................. 7
FiveFocusingStepsofTOC(TheoryofConstraints)............................................... 8
AbouttheAuthor .................................................................................................. 11
AboutGeometric .................................................................................................. 12
8/3/2019 Whitepaper Building Test Ability Into Legacy Code Oct2010
4/12
4
GettingreadyforPLM
Introduction
Industry
studies
say
that
about
a
quarter
of
software
development
cost
is
spent
on
TestingMoreovertheinvestmentintermsoftimeandmoneyincreasesexponentiallywiththeageand
sizeofthesoftwareproductorsolution.
Asthecode iscontinuallystretchedtosatisfychangingrequirements; itdevelopsresistanceto
stretch it further.This leads toa lotofqualityrelatedproblems likeFragility[1],whereasmal
legitimatechangeinoneareacausessomeotherareatofailinamannerthatcannotbelogically
explained.Effectively,stakeholdershaveapoorconfidenceonthequalityofsoftwareproduct.
To address this problem project managers have been investing heavily on Test Automation
There is a wealth of tools available in the market that helps testers to chop down the testing
turnaround
time
to
a
great
extent.
Though
valuable,
these
tools
have
got
some
inherenlimitations:
Thesetests(ortestscripts)arenotreadableenoughtoconveythe intentofwhat isbeingtested.
Theydonotprovideimmediatefeedbackthatdevelopersreallyneed. Theyarenotlightweightenough.The limitationsare inherentbecausetheyaredesignedtomainlycatertotheneedsoftesters
Thesetestsarewrittenaswellasmaintainedbytesters.Thereareotherimportantstakeholder
likedevelopersandproductmanagers,whoalsoneedautomatedtestsfordifferentreasons.
Experienced
software
architects
recommend
the
best
practice
of
building
testability
right
into
the software design/ code. Design for Testability has gained a lot of attention, and over the
years practitioners have built good wisdom on it in the form of various design principles
patterns,etc.
However,thingsarenotsostraightforwardwhen itcomestobuildingtestability intothecode
base thathasbeenaround forquitea fewyears.Designchoicesareoften limitedbyhowthe
existingstructurehasevolvedovertheyears. Implicitassumptionsand lackofdocumentation
whichisnotuncommon,makesunderstandingofexistingdesignevenmorechallenging.
Focusofthispaper istosharechallenges facedandtechniquesused inbuildingtestability into
legacycode
in
order
to
have
continual
quality
improvements
in
the
software
system.
Background
Thispaperbuildsontheexistingknowledgebaseavailableinthepublicdomain,whichhasbeen
builtovertheyears.Thishasbeencontributedtonotonlybysoftwareprofessionals,butalsoby
practitionersfromotherstreams.
8/3/2019 Whitepaper Building Test Ability Into Legacy Code Oct2010
5/12
5
GettingreadyforPLM
Techniquesdiscussedhereareinspiredfromandisbuiltuponthefollowingprinciplesources:
Thebook"WorkingEffectivelyWithLegacyCode"byMichaelC.Feathers. TheoryofConstraintsconceivedbyDr.EliyahuM.Goldratt. ThebookTHEGOALbyDr.EliyahuM.Goldratt Thebook"Refactoring:ImprovingTheDesignOfExistingCode"byMartinFowler.
WhatisLegacyCode?
Different people may have different perceptions about Legacy Code. However this paper uses
the definitionprovidedbyMichaelFeathers inhisbook WorkingEffectively withLegacyCode
Thedefinitiongoesasfollows:
Lookingat
the
code
base,
lets
ask
ourselves
the
following
questions:
Isthecodeeasytochange? DoIgetnearlyinstantaneousfeedbackwhenIchangeit? DoIunderstandit?IfanswertotheanyoftheabovequestionsisNO,thenwehavealegacycode.
Legacycodehasgotaninterestingcharacteristic:
Itworksaslongaswedonttouchit!
Nevertheless,we
need
to
modify
code
in
order
to
change
its
behavior
in
the
form
of
fixing
bugs
or implementing change requests. Quite often developers do not have an adequate
understanding of the design;hence, themodificationsmade in thecodeare suboptimal. This
leads to piling of Technical Debt[2], which leads to increase in the entropy[3] of software
systems. Software systems degrade over a period of time. This is not because of lack o
competencyofdevelopers,but it isan inherentpropertyofanysystem.Thechallenge is how
canwereducetherateofdegradation?Orcanweevenreversetheentropy?Buildingtestability
isallaboutreversingtheentropyofsoftwaresystems.
FundamentalChallengesinBuildingTestabilityintoLegacyCode
Development team can deliver high quality software that meets customers needs and
expectation in given time frame only when they get an early feedback. This is a fundamenta
assumption.
Wearebuildingtestabilitysothatthesystemcanprovideimmediatefeedbacktothedevelopers
onwhatcodetheyarewriting. It isadvisabletocoverasafetynet in formofautomatedtests
beforemakingseriouschangesinthecode.
8/3/2019 Whitepaper Building Test Ability Into Legacy Code Oct2010
6/12
6
GettingreadyforPLM
There is a challenge in bringing the code under suite of tests. Very often legacy code doesn
havewelldefinedmoduleboundaries.CodethathandlesGUI(GraphicalUserInterface)isoften
mixed with business logic. Algorithms are often coupled with code that talks to database
Couplingisawellknownmajorchallengeinsoftwaredesign.Inmanycasesinitialdesignofthe
system is modular, but the boundaries get blurred as requirements change, experienced
developersleaveandknowledgeisnoteffectivelytransferred.
Given that legacycode isnot typically test friendly,onehas tomodify it tobring itunder tes
harness.Nowhereistherealdilemma.Asdiscussedinprevioussections,legacycodeistypically
fragile.Aninnocent,legitimatechangeinmodulecanmakesomethingelsefailinamannerthat
cannot be logically explained. Refactoring is often more aggressive, and hence, risky. So
developersareoftenadvisednottomodifythecodeunlessthereisnoworkaround!
SowehaveadeadlockasshowninFigure1.Therealchallengeishowto
Fig1:Thedeadlockfacedinworkingwithlegacycode
TheSeamConcept
Seam[4]isaconceptasdescribedbyMichaelFeathersinhisbook,whichhelpsusinbreaking
thedeadlock.DefinitionofaSeamisasfollows:
Aseamisaplacewhereyoucanalterbehaviorinyourprogramwithouteditinginthatplace.
Inthecode(irrespectiveofitbeingalegacycodeornot)therearealwayssomepointsthatcan
act as hooks or can be converted into hooks, where we can write additional code to change
behavioroftheprogram.Effectivelythesearetheseams.
Everyseamhasanenablingpoint,aplacewherewecanmakethedecisiontouseonebehavio
oranother.
Thebookdescribesfollowingtypesofseams,whichwecouldsuccessfullyexploitinourprojects:
ObjectSeams:Exploitthepolymorphism PreProcessorSeams:ThisisavailableinlanguageslikeC/C++whereapreprocessingstepis
involvedbeforecompilingthecode.
8/3/2019 Whitepaper Building Test Ability Into Legacy Code Oct2010
7/12
8/3/2019 Whitepaper Building Test Ability Into Legacy Code Oct2010
8/12
8
GettingreadyforPLM
1. IdentifytheCONSTRAINT2. EXPLOITtheCONSTRAINT3. SUBORDINATEeverythingelsetothetuneofabovedecision(s)4. ELEVATEtheconstraint5. Iftheconstraintisbrokenthengobacktostep#1.
IMPORTANT:NeverallowINERTIAtobecomeaconstraint.
ApparentlySystemB ismorecomplexthanSystemA.Howeveracloser lookrevealssomething
different. System A hasgot four degreesof freedom. One has to manage these fourpoints in
orderto improveSystemA.StructureofSystemB issuchthatthere isonenodethat isheavily
dependeduponbyall theothernodes,eitherdirectlyor indirectly.Any improvementmade in
thisnodedirectlytranslatestotheimprovementintheoverallsystem.
Software systems too exhibit a similar behavior. Irrespective of how huge the code base is o
how complex the system is, there exists a simplicity which can be exploited. In fact the Seam
concept discussed above is an example of simplicity, while the concept of enabling point is
abouthowtoexploitthesame.
FiveFocusingStepsofTOC(TheoryofConstraints)
TheoryofConstraintsfurthergeneralizesthisasdealingwithconstraints.Intheaboveexample
ofSystemB,there isonenode inthesystemwhich limitsorratherdeterminesperformanceo
the overall system. Any effort spent on improving this node directly translates to the overal
systemefficiency.Thisnodeiscalledasconstraint.
TOCadvocatesfollowingfivefocusingstepstoachievecontinualimprovementinthesystem:
These five focusingstepseffectivelyworkwithawiderangeofsystems includingoursoftware
systems.Thestepsaregeneralandtheirsequencemustbeenforced.However,implementation
ofthesestepscanvarydependingonthecontext.
Now let us look at how these steps can be implemented in context of a software system to
achievecontinualimprovement.
STEPI:IdentifytheConstraint
Usuallyanexperienceddeveloper,QAorprojectmanagerhassomegutfeelingregardingwhere
theconstraintis.Inmanycasesthisgutfeelingiscorrect,butitcangowrongaswell.Identifying
8/3/2019 Whitepaper Building Test Ability Into Legacy Code Oct2010
9/12
9
GettingreadyforPLM
the constraint is the critical step. If this is identified incorrectly, then efforts spent on
improvementmaynotdirectlytranslateintosystemimprovements.
Hence,it
is
desirable
to
have
some
analytical/
evidence
based
approach.
Following
are
possible
(butnotlimitedto)waystoidentifytheconstraint,whichcanactuallybemeasured:
Identifywhichpartsofthesystem(e.g.module,package,function)aremodifiedquiteofteninordertofixbugs.
Identifywhichpartofthesystemisdependeduponheavilybyotherpartsinthesystem. Identify which parts of the system contain code that is difficult to understand, rigid and
fragile.
Thiswillprovideusthemoduleswhichareinheavydemandtochangeandatthesametimeare
quitedifficulttochange.Thesearethehotspotsinthecodebaseandthecandidatestobecalled
CONSTRAINTS.
Followingaresomemechanismtodothesame:
Bug/RegressionAnalysis:Analysisofrecently introducedbugs/regressionsmayrevealthemodules in the system they originate from. Many bug tracking systems provide tigh
integrationwithSoftwareConfigurationManagementtools.Thismay revealwhich parto
thecodeismodifiedquiteoftentofixbugs.
VersionControlAnalysis:Therearesomeopensourceaswellasproprietarytoolsavailablethat run on version control systems (or configuration management system) to reveal the
trend inwhichpartofthecodebase ismodifiedquiteoftenandthemanner inwhich it is
gettingmodified.
StaticDependencyAnalysis:Therearetoolsavailable inthemarketthatcanperformstaticanalysisofthecodeandinferthedependencystructureofthesystem.Therearesomewell
defined metrics used in software engineering that tell whether the given dependency is
desirable or not. Some examples are Stability, Abstractness, and Distance from Main
Sequence[6].
Dynamic Dependency Analysis: As against static analysis, these tools actually execute thecodeinordertoseewhichpartsofthecodeareexecutedquiteoften.
ComplexityAnalysis:Staticanalysistoolscanalsorevealwhichpartsofthecode(intermsomodules,classes,functionsetc)containhighlycomplexcode.Thiscanbemeasuredinterms
ofCyclomaticCodeComplexity[7].
Goodthingaboutthesemechanismsare:
Theyworkonwelldefinedmetrics,and Theyarenondestructive.
AttheendofthisstepweshouldbeabletoarriveattheCONSTRAINT.
8/3/2019 Whitepaper Building Test Ability Into Legacy Code Oct2010
10/12
10
GettingreadyforPLM
STEPII:ExploittheConstraint
Since constraint is something that limits or determines performance of the overall system, i
needs
to
be
utilized
to
its
full
potential.
Following
are
possible
(but
not
limited
to)
ways
toachievethesame:
Assign best/ experienced developers to work on the module which is identified asCONSTRAINT.Sincetheyaresupposedtoknowthecodeverywell,theywillmakechanges
thataremorelikelytobeappropriate.
Code Reviews: Every change made in theconstraint module needs to be reviewed with amagnifyingglass.
Identify SEAMs in this module so that it can be brought under tests. This requires someminorrefactoringwhichissupposedtobelessrisky.Thiskindofrefactoringmainlyworkson
dependency breaking technique described in the book "Working Effectively With Legacy
Code".
StartwritingautomatedtestssuchthatallthecodeintheconstraintmodulewillgetcoveredItdoesnotreallymatterwhetherthesetestsarewrittenatUnitleveloratSystemlevel.The
objectiveistocoverthecodebyautomatedteststhatwouldprovideanimmediatefeedback
STEPIII:Subordinateeverythingelsetoabovedecision(s)
One important thing that TOC advocates is getting rid of local optimization. All parts of the
systemdonthavetobe100%efficient.
This
effectively
translates
to
focus.
Staying
focused
is
important.
That
does
not
mean
other
areasaretobeignored,buttheeffortsmustbefocusedonbreakingtheconstraint.
Otherareasneedeffortsthatarejustgoodenough.
Thiscanbeachievedbythefollowingpossible(butnotlimitedto)mechanisms:
Seeifthechangerequestscanberoutedsuchthattheydonotneedtomodifythecodeintheconstraintmodules.
Exploitmechanismssuchaspolymorphism inObjectOriented language(providedthecodefollowsobjectorientedparadigm).Typicallyonecanthinkofsubclassingandputnewcode
in the subclasses rather than actually modifying the code in constraint module. This
confirmstothewellknownOpenClosedPrincipleinsoftwareengineering.
Automatecodereviewsbyusingstaticcodeanalysistools.Thesetoolsrelievealotofeffortsfrommanualcodereviewsandthesavedeffortscanbeusedtostayfocusedonconstrain
modules.
Subordinationmayneed tohave a change inpolicy as well. For example, many project teams
haveapolicyof100%codereview,i.e.eachandeverylineofthecodechangemustbemanually
reviewed. It isgood tohave100%codereviews,but inmanycases itmaynotbeeffective,o
8/3/2019 Whitepaper Building Test Ability Into Legacy Code Oct2010
11/12
11
GettingreadyforPLM
ratheritmayprovetobecounterproductive.Useoftoolsforautomatedcodereviewshelpstoa
greatextent.
STEPIV:ElevatetheConstraint
This is the real objective that works towardsbreaking the constraint. This effectivelyneeds to
modifydesignofthecodesuchthatitiseasytounderstandandeasytochange.Essentiallythis
shouldbedonewithoutmodifyingexternalbehaviorofthecode.Thiswayofimprovingdesigno
existingcodewithoutchangingitsbehavioriscalledRefactoring[8]
Overtheyears,Refactoringhasbecomeadisciplinedareainsoftwareengineering.
There are well defined techniques available for refactoring. A book by Martin Fowler on
Refactoringisanexcellentvaluableresourceforthesame.
Refactoringeffectivelyreversestheentropyofthesoftwaresystem.
STEPV:Iftheconstraintisbroken,thengobacktostepI
StepV isnot infinite; ithasadefiniteendpoint. Inordertoknowwheretostop,oneneedsto
have tab on various metrics and how the code base, especially the constraint module is
improvingagainstthemetrics.
As the code is refactored and becomes simpler, at some point of time it no more remains a
constraint.
However,the
fundamental
belief
of
TOC
is
that
the
system
performance
is
always
limited
by
a
constraint.Iftheaboveconstraintisbroken,effectivelyitmeanstheconstraintisnowshiftedto
somewhereelse, i.e. tosomeothermodule inthesystem.Thisonceagainmeans,any furthe
effortsspentonthecurrentmodulewillnomoretranslateintotheoverallsystemimprovemen
andwillonlyresultinlocaloptimization.
HenceonehastogobacktoStepI,i.e.IDENTIFYtheNEWCONSTRAINT.This isaneverrunning
processmeaningCONTINUALIMPROVEMENT.
AbouttheAuthor
ManojPhatak
works
in
the
field
of
Software
Engineering
with
Geometric
Limited.
He
has
been
associatedwithsoftwareproductdevelopmentinGeometricforaboutnineyears,andhasmore
than 15 years of professional experience spanning manufacturing engineering and software
8/3/2019 Whitepaper Building Test Ability Into Legacy Code Oct2010
12/12
12
GettingreadyforPLM
Disclaimer
AuthorandGeometricLtdrespectstheIntellectualPropertyRightsforeverysource itrefersto
Carehas
been
taken
to
ensure
that
credits
are
mentioned.
However,
it
is
possible
for
some
of
the
thingstobeoverlooked. Ifanysuchthing isobserved, it ispurely incidentaland it isasincere
requesttobringitthenoticeoftheauthor.
References
1. Fragility:http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf2. TechnicalDebt:http://www.martinfowler.com/bliki/TechnicalDebt.html
http://www.c2.com/cgi/wiki?TechnicalDebt
3. SoftwareEntropy:http://en.wikipedia.org/wiki/Software_entropy4. TheSEAMModel:
http://ptgmedia.pearsoncmg.com/images/0131177052/samplechapter/0131177052_ch04.p
df
5. TheoryofConstraintsconceivedbyDr.EliyahuM.Goldratt.http://en.wikipedia.org/wiki/Theory_of_Constraints
6. OOADMetrics:http://www.objectmentor.com/resources/articles/oodmetrc.pdf7. CyclomaticCodeComplexity:http://en.wikipedia.org/wiki/Cyclomatic_complexity8. Refactoring:http://en.wikipedia.org/wiki/Code_refactoring
AboutGeometric
Geometric (www.geometricglobal.com) is a specialist in the domain of engineering solutions
services and technologies. Its portfolio of Global Engineering services and Digital Technology
solutionsforProductLifecycleManagement(PLM)enablescompaniestoformulate,implement
and execute global engineering and manufacturing strategies aimed at achieving greate
efficienciesintheproductrealizationlifecycle.
Headquartered in Mumbai, India, Geometric was incorporated in 1994 and is listed on the
BombayandNationalStockExchanges.ThecompanyrecordedconsolidatedrevenuesofRupees
5.12billion(USDollars108.1million)fortheyearendedMarch2010. Itemployscloseto3000
people across 11 global delivery locations in the US, France, Romania, India, and China
Geometric isassessedatSEICMMILevel5for itssoftwareservicesand ISO9001:2000certified
forengineeringoperations.
Thecopyright/trademarksofallproductsreferencedhereinareheldbytheirrespectivecompanies.
http://ptgmedia.pearsoncmg.com/images/0131177052/samplechapter/0131177052_ch04.pdfhttp://ptgmedia.pearsoncmg.com/images/0131177052/samplechapter/0131177052_ch04.pdfhttp://ptgmedia.pearsoncmg.com/images/0131177052/samplechapter/0131177052_ch04.pdfhttp://ptgmedia.pearsoncmg.com/images/0131177052/samplechapter/0131177052_ch04.pdf