whitepaper building test ability into legacy code oct2010

8/3/2019 Whitepaper Building Test Ability Into Legacy Code Oct2010

1/12

W

HITE

P

APER

BuildingTestabilityinto

LegacyCode

Version1.0

October,2010


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.


3/12

3

GettingreadyforPLM

Contents

Introduction ............................................................................................................ 4

Background ............................................................................................................. 4

WhatisLegacyCode? ............................................................................................. 5

FundamentalChallengesinBuildingTestabilityintoLegacyCode ........................ 5

TheSeamConcept .................................................................................................. 6

FurtherChallengesinBuildingTestability .............................................................. 7

FiveFocusingStepsofTOC(TheoryofConstraints)............................................... 8

AbouttheAuthor .................................................................................................. 11

AboutGeometric .................................................................................................. 12


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.


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.


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.


7/12


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


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.


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


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

[email protected]


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

whitepaper building test ability into legacy code oct2010

Documents