Functional Testing: A Pattern to Follow and the Smells to Avoid

Transcription

1 Functional Tsting: A Pattrn to Follow and th Smlls to Avoid Amr Elssamadisy Gmba Systms Amhrst, MA amr@lssamadisy.com Jan Whitmor 1860 Shrman Evanston, IL janimal@gmail.com ABSTRACT Functional tsts ar automatd, businss procss tsts co-ownd by customrs and dvloprs. Thy ar particularly usful for rscuing projcts from high bug counts, dlayd rlass, and dissatisfid customrs. Functional tsts hlp projcts by lucidating rquirmnts, making projct progrss visibl, and prvnting bugs. W prsnt functional tsting in pattrn format bcaus it is spcially xprssiv in convying xprt advic and nabls th radr to mak an informd dcision rgarding th applicability of th solution. Th pattrn prsntd aggrgats multipl xprincs with functional tsting ovr svral agil dvlopmnt projcts. Howvr, w hav sn functional tsting bcom mor costly than its bnfits, so w dscrib th symptoms smlls of potntially costly problms. Ths ar not problms with functional tsting pr s, but with th misintrprtation and mis-implmntation of this practic. W draw on our xprinc to suggst ways of addrssing ths smlls. Don right, functional tsting succssfully incrass softwar s quality and businss valu. Catgoris and Subjct Dscriptors D.2.1 [Rquirmnts/Spcifications] D.2.5 [Tsting and Dbugging] Gnral Trms Tsting, Pattrns, Agil Dvlopmnt Practics Kywords Functional Tsting, Accptanc Tsting, Pattrns, Agil Dvlopmnt Practics 1. COST-EFFECTIVE FUNCTIONAL TESTING Many of us ar familiar with projcts that bgan as a joy to work on, but as thy grw, incrasingly suffrd from high bug counts, dlayd rlass, and dissatisfid customrs. Functional tsting th practic of customrs and dvloprs co-writing businss procss tsts that xcut automatically can hlp solv ths problms. Functional tsts spd rlass by prvnting bugs and shortning th tsting cycl. Thy can automatically dtrmin whthr an application is doing what customrs xpct. Thy can also hlp customrs communicat rquirmnts in a prcis, consistnt way to dvloprs as a form of xcutabl rquirmnts. A projct with functional tsts can continu to b a sourc of prid and joy vn as it grows in siz and complxity. So why has functional tsting not bn mbracd as commonly as unit tsting in th agil community? Why do many of our collagus complain that th costs of functional tsting xcd th bnfits? W bliv that popl who hav givn up on functional tsting hav lackd th right tools and tchniqus. Aftr all, how many unit tsts would you writ without xunit and a continuous build? How much rfactoring would you do if you wr coding in a txt ditor? Th right tools and tchniqus can mak functional tsting asy and chap. In particular, w rcommnd tchniqus for making functional tsting fast nough to b in th continuous build (and at last as fast as th typical chck-in cycl in a non-agil dvlopmnt nvironmnt). W also xplor tchniqus that mak diagnosis of tst failurs rlativly asy. Howvr, somtims vn th right tools arn t nough. If stting up a functional tst is onrous, th root problm may b th architctur of th systm undr tst. This phnomnon is similar to th ida that if stting up an objct in a unit tst harnss is spcially hard, thn th objct probably has too many dpndncis. W will suggst architctural changs such as improvd modularization of subsystms and moving businss logic out of th Graphical Usr Intrfac (GUI) and into a srvic layr [1]. Ths changs mak functional tsting asir whil making th architctur bttr. In this papr, w assum functional tsting is don within an agil dvlopmnt [2] nvironmnt, although w offr a fw variations for a traditional dvlopmnt nvironmnt. Our focus is also on functional tsts that xrcis all layrs xcpt th GUI, but most of our pattrns and smlls apply to othr typs of functional tst. W will point out whn thy do not. W bgin by dscribing functional tsting in a pattrn format so that radrs can dtrmin whthr th practic is appropriat for thir projcts. Thn w idntify functional tsting smlls signs of costly problms and th tchnical and architctural solutions that addrss thm. W hop popl will rcogniz th

2 nd for bttr tchniqus rathr than giving up on functional tsting. Th bnfits ar just too good to pass up. 2. Functional Tsting: An Agil Practic Pattrn Pattrns allow us to propos dvlopmnt practics as potntial solutions to a common st of problms. By dscribing functional tsting in a pattrn format, w mpowr radrs to mak thir own valuation of this dvlopmnt practic. Using functional tsting is thn not a stark black or whit dcision; it dpnds on how much a dvlopmnt tam has xprincd th problms and whthr this pattrn as a proposd solution is within rasonabl costs. W includ svral storis and narrativs to bring hom th points basd on spcific xprincs w hav had. Automatd, Businss Procss Tsts In this papr, w dfin functional tsts as businss procss tsts that ar co-ownd by customrs and dvloprs and that can b automatically xcutd. Functional tsts can b bttr undrstood by comparing thm with what thy ar not. First, functional tsts ar not ownd by a tsting dpartmnt (which may or may not b part of a Quality Assuranc dpartmnt). Instad, thy ar ownd by i.. cratd and maintaind by customrs. In ordr for customrs to b ownrs, th functional tsting tool must provid a way for customrs to rad, writ, and xcut tst spcifications, although dvloprs may implmnt tsts and th tsting dpartmnt may hlp dvlop mor ffctiv tsts. Scond, functional tsts ar not manually run. No on nds to click on scrns or st up data in ordr to xcut thm. Instad, functional tsts, lik unit tsts, ar compltly automatd. Howvr, unlik unit tsts, functional tsts ar not focusd on isolatd units of cod, whos propr bhavior a dvlopr dfins. Instad, thy xrcis a usful businss procss, whos corrct outcom is dfind by a customr. W spak of a businss procss bcaus w man mor than just th static businss ruls; w man also th squnc of stps that invok th businss ruls to gnrat a usful outcom. If us cass ar usd, thn ach scnario of a us cas can b covrd by a functional tst. Our goal is to assur that th program dos somthing usful for a ral usr. If functional tsts covr mor than a unit, just how much should thy covr? Thr ar svral options, dpnding on th typ of tsting you want to do. Our xprinc is primarily with functional tsts that ar drivn from th srvic layr (or control layr or systm-façad layr), a layr btwn th GUI and domain layrs on n-tir systms. That is, our functional tsts xrcis all layrs xcpt th GUI so that thy ar almost ndto-nd. W will call ths srvic-drivn functional tsts. Many functional tsting tools driv tsts through th GUI. Som of th pattrns w dscrib also apply to ths GUI-drivn tools. Howvr, th tsts of GUI-drivn tools ar oftn mor fragil than thos of srvic-drivn tools bcaus thy may brak whn a button is movd. Mor importantly, GUI-drivn tools do not hav th architctural bnfits of srvic-drivn tools. For xampl, thy do not hlp driv businss logic out of th GUI [3]. Forcs Th forcs in a pattrn ar th driving factors that lad to th implmntation of th pattrn. Pattrns can b considrd as problm/solution pairs. Th forcs ar th problms that ar addrssd by th pattrn as a potntial solution. Th main forcs pushing us to try functional tsting ar too many bugs, dlayd rlass, and poorly capturd rquirmnts. Bugs Incras As Intr-Modul Dpndncis Grow Most dvlopmnt groups that w hav sn try functional tsting wr motivatd primarily by a dsir to rduc bugs. That is, whn thy har th phras functional tsting, thy particularly focus on th word tsting. Unit tsts can kp individual classs fairly fr of bugs, but thy do not addrss intr-modul bugs. Furthrmor, as th cod bas grows, th numbr of potntial intr-modul bugs grows fastr. Dlayd Rlass As th application grows and th product maturs, th tsting dpartmnt cycl can tak longr, causing incrasingly dlayd rlass. Slow Manual Tsting Manual tsting by a tsting dpartmnt will tak significantly longr with a larg product than a small on. Bcaus manual tsting is slow, th fdback about a bug occurs long aftr th cod changs that causd th problm wr mad. Th dlayd fdback maks it hard to diagnos which chang causd th bug, so fixing a bug found by th tsting dpartmnt taks longr, too. Slow Patchs A corollary of slow rlass is slow patchs for bugs rportd in th fild. In many dvlopmnt nvironmnts, dvloprs hav to st up a full databas and prform many manual stps to rproduc a bug. And thy must rproduc th bug both to diagnos it and to confirm thy hav liminatd it. How much nicr if thy had an asy way to script th systm with th minimal conditions to rproduc th bug! Not Knowing Whn a Task is Don Almost vryon has xprincd a projct that was dclard don and thn continud for wks or months aftrward. With functional tsting, th customr writs tsts that xrcis th businss procss (rprsntd in a us cas, story or fatur) schduld for th currnt itration. Whn th functional tsts pass, th work is don.

3 Poorly Capturd Rquirmnts Imprcis Rquirmnts On of th rasons projcts drag on aftr thy ar dclard don is that th original rquirmnts wr imprcis. Vrbal rquirmnts do not provid nough dtail for coding. Dvloprs guss what th customr mant and call th projct don. But if th dvloprs gussd wrong, th cod will hav to b r-workd Contradictory Rquirmnts Many don projcts gt stuck in th tsting phas bcaus of bug cycls. An xampl of a simpl cycl is that whn bug A is fixd, bug B appars; and whn bug B is fixd, bug A r-appars. But th cycl is rarly that obvious, spcially if A and B ar in diffrnt parts of th systm or tak a long list of manual stps to rproduc. An automatd tst suit could quickly show that both bugs ar nvr fixd at th sam tim. At that point, on might discovr that A and B cannot both b tru at th sam tim bcaus thy ar contradictory. Functional tsts hlp tst our rquirmnts for contradictions. Outdatd Rquirmnts Finally, rquirmnts ar also oftn outdatd. Th longr running th projct, th mor likly that at last som of th rquirmnts hav falln bhind th cod. Lt us b frank hav any of us rally had rquirmnts that wr 100% up-to-dat aftr a yar of dvlopmnt? Outdatd rquirmnts can b mor nfarious than no rquirmnts. If thr ar no rquirmnts, dvloprs will try to xtract thm from th customr, th cod, or th unit tsts, all of which ar likly to provid fairly up-to-dat information. But outdatd rquirmnts ar misinformation. Thy can wast a lot of tim by snding dvloprs down th wrong track. Dscription Functional tsting is much mor than automatd accptanc tsts; th st of tsts can b considrd xcutabl rquirmnts. That is, thy ar rquirmnts writtn by th customr (somtims with th hlp of a dvlopr dpnding on tool support) that can b run and ithr passd or faild. Unit tsting is oftn practicd with tst-drivn dvlopmnt. Th dvlopr writs a tst for a cas th cod cannot yt handl. Bcaus th cas has not bn implmntd yt, th tst fails, rsulting in a rd bar in th unit tst GUI. Thn th cod to pass th tst is writtn, which turns th bar grn. Thn th cycl is rpatd in a rd-grn-rd rhythm. Functional tsts tak th rd-grn-rd loop of unit tsting to th lvl of rd-grn-rd loops for adding nw businss functionality to th application. From that point of viw, functional tsts allow th dvlopr to know whn sh is don with th task at hand as indicatd by th customr. This rducs a larg amount of ffort whr cod is submittd to th customr or tsting group only to b found lacking in functionality and b brought back into th dvlopmnt group. A major oftn uncitd contribution of functional tsting is th improvmnt of th architctur of th systm undr tst. Functional tsts forc businss logic to b rmovd from th GUI and movd into th srvic layr, whr th functional tsts can xrcis it. Functional tsts also ncourag modularity and th sparation of subsystms, analogous to how unit tsts forc loos coupling btwn objcts for tstability. This ida is still nw to us but w hav found that it rings tru with othrs with similar xprincs. Anothr major contribution of functional tsting is that it tsts an ntir st of possibl rrors that is not addrssd by unit tsting. As any xprincd objct-orintd programmr knows, a significant part of th complxity of an objct-orintd systm is in th rlationships btwn th objcts. Functional tsting xrciss ths complxitis as unit tsting cannot (and is not intndd to). Softwar quality incrass. And dvlopmnt can procd at an vn fastr pac than unit tsting nabld. A fourth contribution of functional tsting shows up mor in th latr stags of a projct as it ntrs maintnanc mod; bugs rportd ithr by th tsting tam or th customr com in to th dvlopr as a st of stps for rproduction. Th immdiat rspons for a dvlopr whn functional tsting is availabl is to writ a failing functional tst to rproduc th stps. Thn sh digs in, finds th problm, writs a failing unit tst, and fixs th problm, causing both th unit and functional tsts to go grn (most of th tim). This tchniqu, which is nabld by functional tsts, catchs th fals fixs whr th dvlopr finds th bug, writs th unit tst, and assums th bug has bn fixd whn it truly is not. Not that for all of ths bnfits, th functional tst suit must b part of th continuous intgration build. If functional tsts ar not in th build, thy can asily bcom a liability instad of a bnfit, a situation w dscrib in th smlls blow. Variations Covring th Domain Only This papr focuss on functional tsts that xcut logic from th srvic layr through th domain layr all th way down to prsistnc. Not all functional tsts must xrcis all ths layrs; in fact Mugridg and Cunningham [3] argu for writing functional tsts to xrcis th domain logic only. Such tsts ar still usful, but thy do not covr th subsystm boundaris, which ar bug-pron. Th domain-only approach is a viabl altrnativ if running nd-to-nd tsts within a dvlopr chck-in cycl is infasibl. Functional Tsts Writtn By Committ W argu that customrs or analysts should writ functional tsts bcaus thy ar in th bst position to writ rquirmnts. Howvr, tstrs and dvloprs can join customrs and analysts to co-writ tsts. Tstrs bring thir xprtis in tst-cas dvlopmnt and hlp writ rquirmnts that covr th ncssary

4 dtails. Dvloprs may b ndd to hlp mak th rquirmnts xcutabl dpnding on th tool. For xampl, th Framwork for Intgratd Tsts (FIT) tool [4] rquirs dvloprs to writ fixturs bfor tsts can xcut. W hav found that writing tsts by committ usually happns primarily in th bginning stags of adoption of functional tsting as analysts larn to think lik a tstr, and dvloprs build thir domain languag. In latr stags, writing tsts by committ taprs off and th brunt of tst authoring falls to th analysts with occasional hlp from othrs in th dvlopmnt group. Functional Tsts Writtn With Unit Tsting Tool Som tams writ thir functional tsts with a unit tsting tool such as NUnit or JUnit. Using an xunit tsting tool covrs cod adquatly but loss involvmnt from customrs and analysts, sinc th tsts ar now codd in a languag that thy can nithr writ nor rad. It bcoms th dvlopr s job to translat th rquirmnts into ths tsts. Th status of th tsts as passing or failing is also not visibl to ithr th customr or tsting group. W considr functional tsts in xunit to b rathr hobbld bcaus of th xclusiv focus on covrag. Ths tsts ar indd bttr than no functional tsts but could b considrd a smll. Functional Tsts Within a Traditional Dvlopmnt Environmnt Our xprinc with functional tsting is within an agil dvlopmnt nvironmnt, but thr is no rason it cannot b usd on non-agil projcts. Th ky point is that th functional tsts must b run at a frquncy that matchs th dvlopr chck-in cycl. That way, th sourc of failing tsts can b idntifid. All of th bnfits of agil functional tsting ar achivd, just at a slowr cycl tim bcaus thr is no continuous intgration build. Whn don in this nvironmnt, th mphasis on spd of running tsts is rducd bcaus th chck-in cycls ar typically much longr. Bnfits Whras forcs push us toward a pattrn, bnfits pull us. Forcs dscrib a problm that th pattrn will solv. In contrast, w obtain th bnfits vn if w do not currntly hav any problms. Dvlopmnt Tam Has Mor Confidnc Thr is a dfinit sns of confidnc that dvloprs acquir whn thr is a solid tst framwork that thy rly upon. Unit tsting and TDD hav gon a long way in making dvloprs mor confidnt of thir cod. This is not mrly a warm-fuzzy fling (which is always good for moral), but nabls fastr dvlopmnt bcaus dvloprs chang what nds to b changd via rfactoring. Functional tsts tak this confidnc up a notch or two abov and byond unit tsting. Thy also improv th confidnc of th customrs/analysts and tstrs bcaus thy hav a dirct rlationship to th rquirmnts and rgrssion tsts. Thy know a grn tst is a non-ambiguous indication that th rlatd scnario is working. Robust Tsts Srvic-drivn functional tsts skip th GUI and focus on businss logic. Businss logic tnds to b fairly stabl, and so th tsts don t hav to chang much. In contrast, automatd tsts that hit GUI lmnts brak whn GUI lmnts ar r-arrangd. Errors and Bugs ar Rproducibl Quickly Onc a bug is found, a functional tst is writtn, and that bug dosn t com back to haunt us. A unit tst should also b writtn around th buggy cod, of cours, but whn dvloprs first bgin invstigating a bug, thy don t know whr to writ th unit tst bcaus thy don t know which unit causd th problm. But thy (hopfully!) know which us cas causd th problm, so thy should b abl to writ a functional tst immdiatly. By writing tsts as soon as bugs ar discovrd, w liminat th bug-fix-brak thrashing that happns whn systms bcom brittl. W hav found that whn a systm movs from initial dvlopmnt to production that th amount of tim spnt dvloping nw functionality dcrass. With a functional tsting framwork at hand th businss languag has alrady bn built and it bcoms vry straight-forward (mor than for unit tsting) to build a functional tst that xactly rproducs th rror basd on th bug rport. This allows th dvlopr to hav an xcutabl rproduction of th bug that can b usd for digging into th cod rpatdly without having to kp stting up th nvironmnt just so. Tstrs Hav Tim to B Mor Pro-Activ If Slow Manual Tsting is a rason to try functional tsting, thn quick automatd tsting is a bnfit. Th consqunc is that tstrs ar rlivd of much of th day-to-day burdn of manual tsting of th main businss ruls. Instad, tstrs hav mor tim to b pro-activ, collaborativly hlping dvloprs dsign mor tstabl cod, rathr than waiting to clan up at th nd of an itration. Whn a Task Is "Don" is Visibl for All Rcall that without functional tsting, w ar drivn by th forc of Not knowing whn a task is don. Using functional tsting dos hlp us know whn a task is don, but it s mor than just that. Functional tsting maks progrss visibl to th ntir dvlopmnt tam customr, analyst, dvlopr, tstr, and managr. At any point in tim all passing (and failing) tsts can b viwd. With a littl ffort businss valu producd at a functional lvl can b analyzd for managmnt nds. Bttr Dsign, Bttr Architctur Functional tsting drivs bttr layr and subsystm sparation. Considr th layrs of a multi-tir architctur. Sinc th functional tsts xcut through th srvic layr, vry bit of businss logic

5 that has found its way into th prsntation layr must ithr b duplicatd in th tst fixtur or pulld into th srvic layr. W xplor this point in mor dtail in sction 4.1. Similarly, considr th subsystms of th systm th moduls with functional rsponsibility, such as a modul for tax calculations. As w show in sction 4.2, any tax logic that has lakd out of th tax modul will b duplicatd in th tst fixtur unlss it is movd into th tax modul. Functional tsts hlp solidify th rsponsibilitis of a subsystm. Analysts Think Through Rquirmnts in Gratr Dtail Analysts think through rquirmnts in gratr dtail to achiv th dscriptions ndd to writ a tst. For xampl, an analyst might stat that txtboxs should b disabld whnvr thy ar not ndd. But whn h writs a functional tst for this rquirmnt, h is forcd to gt xplicit about which conditions caus which txtboxs or rally thir rprsntations in th undrlying srvic layr to b disabld. Improvd Customr-Dvlopr Communication Th concrt xampls codifid in th functional tsts ar not sufficint to spcify rquirmnts. Customrs would not know how to crat such dtail by thmslvs, anyway. Instad, it is th collaboration btwn customrs and dvloprs that hlps flsh out rquirmnts for both of thm. On th whol, functional tsting with rquirmnts spcification can improv communication btwn dvloprs and customrs. Ovr tim, th discussions of th functional tsts hlp th tam dvlop a common vocabulary and a common vision for th systm [4]. Exampls of th dvlopmnt of such collaboration can b found in Mugridg and Cunningham s rcnt book [5]. Whn to Us It Thr ar svral tool rquirmnts whn it coms to functional tsting. Only us functional tsting if you ar abl to mak it part of your build procss. On agil dvlopmnt projcts this mans that it must b part of th continuous intgration build. On mor traditional projcts, th functional tst suit must b run within th granularity of a typical chck-in cycl. If you cannot run your tst suit within th normal chck-in cycl tim, you may find that your tsts ar noisy and oftn failing bcaus thy cannot kp up with th currnt build (mor dtail in sction 0). For functional tsts ralistically to b part of th build, th functional tst suit should not tak mor than 20 minuts to run (as a rul of thumb for agil projcts). To achiv this, th following stratgis hav bn found hlpful: Databas whr tst st is prsnt and rfrshabl/loadabl within an accptabl tim. That mans w hav to activly kp a snapshot to support our suit of tsts. Tsts can us transactions and rollback at th nd of th tst instad of committing (usually 5-10 tims fastr than a committd transaction). Distribut functional tsts on sparat machins vry tim on machin's run taks too long. Finally, you ar rady to introduc functional tsts if you hav th attitud that tsting is a primary dvlopmnt practic and not a scondary practic that can b droppd in a crunch or if it rquirs a larg ffort. Functional tsting dos not com fr, and w will s blow in sction 3 that th cost of cutting cornrs is vry xpnsiv. How to Us Functional Tsting Functional tsting is much mor than just tsting. It is also about communication btwn dvloprs, analysts, and tstrs. It is about undrstanding th rquirmnts, th businss domain, and your systm as a solution addrssing businss problms. Jim Shor stats, In th sam way that tst-drivn dvlopmnt, whn don wll, facilitats thinking about dsign, [functional tsting] don wll facilitats thinking about th domain. This thinking happns at th rquirmnts lvl and at th dsign lvl [6]. Ultimatly functional tsts bcom a domain-lvl languag spokn among th various mmbrs of th dvlopmnt tam. So as you mbark on functional tsts, b sur to focus on communication of rquirmnts and building up of th domain languag. In fact, Functional Tsts Writtn By Committ in sction 0 is an xcllnt way to start off. W would add that srvic-drivn functional tsting also facilitat thinking about systm architctur. You simply can t put much logic in your GUI if you hav to run your functional tsts without th GUI! Functional tsting is also vry tool snsitiv. If th tools ar not up-to-par in spd and fdback thn functional tsts los much of thir bnfit. Onc you hav th right tools, you nd to know how to us thm. Functional tsts should itrativly covr us cass, on thin scnario slic at a tim. 1. Choos on spcific xampl of a path through a businss procss.g. on scnario through a us cas to tst at a tim. Kp th scnario slic thin and dp. That is, tst a small st of functions at a tim and run it from th srvic layr all th way to th databas. W would rcommnd slcting a highrisk slic first,.g. rplicating a rcnt bug, so that tam mmbrs car about th outcom. 2. Minimiz th amount of data in your databas snapshot usd for your tsting. Rmmbr, th smallr th databas, th fastr th rfrsh and th actions that ar prformd in th databas. 3. Mock out xtrnal systms whnvr possibl for spd and indpndnc. A good xampl would b mocking out an xtrnal crdit card authorization srvic for an -commrc application. 4. Howvr, you may want to includ a fw tsts that intrfac high risk xtrnal systms that could caus (or alrady hav causd) your systm to fail if you misundrstand thir API. Th tsts can thn hlp documnt th API. 5. Whnvr a functional tst strip gts too thick.g. if it includs mor than on scnario sparat it into diffrnt tsts.

6 Whn Not To Us It Ar you rady for Functional Tsting? Th long and short of it is this: don t us functional tsts if you ar not willing to put th ffort to writ th tsts. This may turn out to b a non-trivial ffort thr ar dfinit costs. So if you ar not willing to do all of th following, thn mayb functional tsting is not appropriat at this tim: Introduc a tchniqu to dtrmin what coding modifications hav brokn a build. W rcommnd that you mak functional tsting part of th continuous build, but if not thn at last hav a functional tsting cop. This is discussd in dtail in sction 0. Modify your xisting systm for tsting. Most systms built without functional tsting in mind will nd modifications. Many of ths modifications ar not simpl and may involv architctural changs. Sction 5 discusss architctural smlls that will rquir ths typs of changs to nabl usful functional tsting. Suggstd Adoption Stratgy Lik almost vrything in agil dvlopmnt, functional tsting should b adoptd itrativly. B carful that you kp popl ahad of procss. That is, itrat to gt dvloprs and customrs traind and hav thm build a fw functional tsts. Thn, aftr th tam has a fw working functional tsts that ar part of th build, ask thm for fdback on th tools and procsss. Improv your tools and procsss until th dvloprs and customrs ar happy with functional tsting. Thn itrativly xpand th practic to th tam. Whn functional tsts ar not part of th build, thy can caus much mor harm than good and may not catch on or vr b usful. W hav sn this happn and it is not a prtty sight. Adding functional tsts to a lgacy systm i.. on that dos not alrady hav functional tsts can b challnging bcaus th architctur might not allow xcluding th GUI or tsting a singl us cas scnario at a tim. You also may hav rarchitct som of your systm to spd up th functional tsts nough to b part of th continuous build. Functional tsts can initially b addd for nw faturs or to rproduc bugs, with supporting unit tsts addd for th implmnting cod. As w dscrib blow, w do not rcommnd adding functional tsts without unit tsts. During th transition to functional tsts, it can hlp to assign a dvlopr th rol of "Functional Tst Cop." Th cop s job is to track down th dvloprs who brak th functional tsts, hlp thm s why thir cod brok th tst and hlp thm fix th problm. S th narrativ in sction 0 for mor dtail on this rol. 3. EXAMPLE OF FUNCTIONAL TESTING WITH FIT Thos nw to functional tsting might fl frustratd at th gnral natur of th pattrn dscription. How xactly dos it work? For th purpos of hlping you dcid whthr functional tsting is right for your tam, w provid a brif tast of doing functional tsting with a tool w lik, Framwork for Intgratd Tsts, or FIT for short. Our xampl is xtrmly simplifid. Mugridg and Cunninham [5] dscrib how to writ mor complicatd functional tsts with FIT. But w hop this simpl xampl will illustrat our claims about functional tsting s bnfits. A Simpl, Fully Explaind Exampl FIT tsts ar xprssd in tabl form. Th simplst typ of tabl has svral tst input columns on th lft and a tst output column on th right, with ach row rprsnting on tst. (Such a tabl uss what FIT calls column fixturs. ) To add a nw tst, a usr adds a row. H thn typs th input data and xpctd output data for that row. Whn FIT is xcutd, it taks th input data, fds thm into th function undr tst, and compars th output of th function to th xpctd output. It colors th output cll of ach tst grn if th actual output matchd th xpctd output, and othrwis colors th cll rd and insrts th actual valu blow th xpctd valu. Blow is a simpl xampl of a FIT tabl for a payroll calculator. Th first row just tlls FIT which cod to xcut, which w will dscrib mor shortly. Th scond row is th column hadrs. Each rmaining row rprsnts a tst, so thr ar thr tsts in this tabl. Th column hadrs indicat th column typ. Plain hadrs indicat inputs whil hadrs followd by opn and closd parnthss () indicat outputs. So in ths tsts, Hours and Wag ar inputs whil Pay is an output. Accounting.Fixtur.PayrollCalculato r Hours Wag Pay() 10 $20 $ $10 $ $10 $475 Whn FIT is xcutd on th payroll calculator tabl, th first two tsts pass, so thir clls in th Pay() column turn grn, but th third tst fails and turns rd, as shown blow. (If you hav a black and whit printout, th grn should b light shading, and th rd should b dark shading with bold txt.) This third tst is th spcification of a nw fatur. An ovrtim rul will b addd to th payroll calculator in this itration so that hours abov 40 will b applid with 1.5 tims th wag rat. A dvlopr now has not just a dscription of th ovrtim rul but an xampl. Whn th dvlopr is don coding, sh can xcut FIT again, and th third row will turn grn if sh implmntd it corrctly. Accounting.Fixtur.PayrollCalculator Hours Wag Pay() 10 $20 $ $10 $ $10 $475 xpctd $450 actual FIT tsts ar dsignd to b vry xprssiv, so that nontchnical popl can writ and rad th tabls. Furthrmor, sinc ths tabls can b mbddd in HTML or ordinary

7 Microsoft Word documnts, usrs can provid contxt to th tsts. For xampl, for th payroll calculator, th tabl could b prcdd by a vrbal dscription Dmonstrats pay calculation. Th first two tsts just multiply hours by wags whil th third tst dmonstrats that 1.5 * wags ar usd for ovrtim hours. FIT knows to skip ovr vrything but th tabls. In ordr to kp th tst intrfac simpl and imprvious to cod rfactoring, dvloprs usually crat an objct calld a tst fixtur that translats btwn th tst s intrfac and th cod s intrfac. For th payroll calculator, th tst fixtur would hav sttabl public mmbr variabls calld Hours and Wag. Thn it would hav a mthod calld Pay() that dos any ncssary st-up, calls into th appropriat ral objcts in th systm undr tst, and rturns th calculatd pay. A Mor Ralistic Exampl Now, if w ar going to do nd-to-nd tsting of a rasonably complx systm, thr will b far mor complicatd tst scnarios than th on abov. Thy may involv configuration paramtrs for th st-up, conncting to databass and so on. Rst assurd that FIT can do it all, and our xampl was th simplst possibl. FIT tsts can xtnd ovr multipl tabls, som of which do ssntial st-up for othr tabls. FIT also offrs many typs of pr-built fixturs that lt you brak out of th basic NxM grid w dmonstratd. For a complt dscription, w rfr you again to Mugridg and Cunningham [5]. Dspit this xtra complxity, non-xprts can asily undrstand th tabls. To prov our point, w prsnt a mor complx xampl of FIT tsts for a shopping cart application. Th clls in grn rprsnt passd tsts. W bt you can undrstand th rquirmnts vn without knowing how xactly th fixturs work or ar implmntd. Load invntory to b usd for tsts and confirm 5 itms loadd. Fit.ActionFixtur Start com.valtch.srvic.tsts.itminvntoryfixtur Entr Invntory xcutabl rquirmnts../src/com/valtch/post/srvic/tsts/invntor y Chc k Total itms 5 Mak sur th itms hav th corrct UPC, dscriptions and prics. com.valtch.srvic.tsts.itminvntorydisplayfixtur UPC Dscription Pric 2458 Chocolat Cola Milk Eggs Olivs 3.15 Confirm you can slct an itm and chang its dscription. Fit.ActionFixtur Start com.valtch.srvic.tsts.itminvntoryfixtur Entr Slct 2458 Chc k Dscription Chocolat Entr Dscription Dark Chocolat Chc k Dscription Confirm you can add a nw itm. Fit.ActionFixtur Start com.valtch.srvic.tsts.itminvntoryfixtur Dark Chocolat Entr Add itm 1112 Entr Dscription Hon y Entr Pric 5.60 Chc k Total itms 11 Ths xampls dmonstrat that with an xprssiv tsting tool, dvloprs and customrs can collaborat on writing tsts. Th concrt xampls in ach tst ar a mting ground for domain knowldg and cod functionality, undrstandabl by vryon on th tam. Furthrmor, th tabls can b xcutd to nsur that what thy claim should b tru rally is currntly tru which is why thy ar calld living documntation or So if functional tsting is so asy, why isn t vryon doing it? Wll, thr ar a numbr of pitfalls that w dscrib nxt, including how to avoid thm. 4. IMPLEMENTATION SMELLS Your first attmpt at functional tsting might ncountr problms. W v ncountrd two broad classs of functional tsting problms. Th first class involvs th implmntation of th functional tsts thmslvs; th scond is rlatd to th (un)suitability of our systm undr tst. W dscrib ths problms in trms of smlls, which ar arly warning signals that th dvlopmnt procss nds to b rfactord [7]. In this sction, w considr smlls of poor implmntation and offr th tchniqus that can allviat thm. Littl (or No) Accountability for Brokn Tsts If thr is no accountability for brokn tsts, thn thy don t gt fixd. In gnral thr is no accountability if it is difficult to tll

8 whos cod chang brok th tst. W hav found that this usually happns whn th tst-run cycl is significantly slowr than th chck-in cycl of dvloprs; that is, if svral dvloprs hav chckd in thir cod sinc th last tim th tsts wr run, it is difficult to dtrmin whos changs brok th tsts. Solution: Functional Tsts In Continuous Build W strongly rcommnd including functional tsts in th continuous build. Inclusion in th continuous build was also rcommndd in Gandhi t al. s xprinc rport [8]. In a traditional dvlopmnt nvironmnt without a continuous build, th functional tsts should b run aftr vry chck-in. Anothr variation is to us a functional tst cop as dscribd in Slow Tsts Rmovd From Build Stay Brokn blow. Rmmbr, th goal is to idntify th chck-in that brok th tsts. Tchnical Tips for Spd In ordr to gt functional tsts into th continuous build, th tsts must b mad fast nough. First, th tam must mak a commitmnt to functional tsting as a primary dvlopmnt practic instad of a scondary on. Whn it is not an option to drop th tsts, thn tams find crativ solutions. Th main thing is to spd up th running of th functional tsts so thy can b run ffctivly by dvloprs on thir local machins bfor chcking in. Effctiv stratgis w hav found ar: Functional Tsts on Sparat Machins: By grouping tsts into rlatd suits thn ach suit can asily b run on its own machin. This ffctivly paralllizs th tst suit and can giv a spd incras proportional to th numbr of machins usd. Functional Tsts Rollback Databas Transaction: This is a vry simpl but ffctiv ida don t commit your databas transactions if you ar tsting ndto-nd. W hav sn this practic mrg indpndntly on diffrnt projcts and this usually givs about an ordr of magnitud incras in spd. Functional Tsts Rfactord to Thinnr Slics: By tsting a small scnario within ach tst instad of svral scnarios (or vn all scnarios) for a us cas w gt a finr granularity for splitting up tsts. W hav also found that largr tsts tnd to hav mor rdundancy braking thm up allows for fastr individual tsts. Functional Tsts Groupd By Businss Ara: Grouping functional tsts by businss ara allows a dvlopr to tst th subst of rlvant tsts on thir machin without running th full suit. This allows for a fastr rdgrn-rd tst loop and will kp a tst suit from slowing th pac of dvlopmnt. Not that having indpndnt databas sandboxs for ach functional tst run is a prrquisit for th abov advic. If two functional tsts run against th sam databas, on may rport an incorrct failur bcaus of intractions with th data insrtd by th othr tst. Rlatd Smll: Confidnc in Functional Tsts is Lost Laving tsts brokn taks away from much of th valu of th functional tst suit as a safty nt that prvnts bugs from ntring th build in th first plac. Th tsts arn t catching th bugs and hlping us kp th cod in working ordr as w would xpct. Without this safty nt, confidnc in th tsts is lost. Tst writing is rducd, and in th mor srious cass thy ar dltd and finally droppd as a whol. Narrativ: Slow Tsts Rmovd From Build Stay Brokn Th contxt of th following xampl is from a larg lasing application aftr on yar of practicing XP with a 50-prson dvlopmnt tam consisting of about 30 dvloprs, 7 analysts, 8 tstrs and managmnt. Th cod bas was ovr 500,000 lins of xcutabl cod and th tchnology was J2EE with EJB 1.0. Whn w first startd implmnting functional tsts w wrn't quit sur how much valu thy would hav, but w had a vry smart and xprincd consultant advising us to do so. W knw w wr missing intr-objct tsting and our xunit tsts wr tsting unit and mor incrasingly intgration tsts by tsting systms of objcts togthr. W had gratly rducd th rrors found by th tstrs in QA, but thr wr still many gtting through. Also, w had svral cass of th dvlopr saying thy wr don, but whn his cod was rviwd, thr was ithr missing or incorrct functionality vn though th unit tsts passd. So thos wr th driving factors to implmnt functional tsting. But functional tsts wr slow and th build wnt from 20 minuts to 50 minuts. W dcoupld th functional tsts from th build and thir tim shot up from 50 minuts to 120+ minuts ovr th nxt fw months. Now vry 4 or 5 builds, on st of

9 functional tsts would b run, and w didn t know who xactly brok th tst. Svral chck-ins had happnd and vryon knw th failur wasn't causd by thir cod. Th tsts would brak and stay brokn for ovr a wk, and frquntly w ndd somon to stp up and b a hro to clan up thos stupid tsts! Somtims (ok many tims) w thought thy wr mor troubl than thy wr worth. Thankfully, w didn't drop thm. I don't rmmbr who, but somon on th tam stppd up and proposd that w hav a codd functional tst (CFT) cop. This prson had th painful job of watching th CFTs and fixing thm whn thy brok. Of cours this was a pain, and on cop got tird of it and dug into th CFTs to try to mak thm fastr. With a fw solutions such as Functional Tsts on Sparat Machins and Functional Tsts Roll Back Databas Transaction and Functional Tsts Rfactord to Thinnr Slics (dscribd in th sction abov) th CFTs wr running in lss than 20 minuts and brought back into th build. Surprisingly th functional tsts stoppd bing brokn bcaus dvloprs could run thm ffctivly on thir local machins bfor chcking in. Evn if thy missd somthing, th CFT was run with vry build, so brokn unit tsts wr immdiatly fixd bcaus it was (almost always) obvious who th culprit was. Small Cod Changs Brak Many Tsts Whn many tsts fail, on normally assums that a big cod chang must hav bn chckd in. Howvr, if only a small chang causd many failurs, thn thr must b a larg amount of ovrlap of th tsts. Solution: Each Tst Focusd on On Thin Slic Whn ach tst focuss on on thin slic of functionality and dos not ovrlap much with othr tsts, thn it s mor likly that only on or two tsts brak whn a bug is introducd. It is much asir to diagnos why a thin tst faild. Thus, writing tsts to xrcis on thin slic of functionality in on major systm provids th bst fdback on that xampl of a businss procss. Rlatd Smlls If your functional tsts covr too much ground, you may notic ths smlls: Many tst fixturs must b usd in a singl tst Dvloprs gt frustratd with updating many tsts for small cod changs Narrativ: Trying to Tst Evrything W xprincd th smll of small cod changs braking many tsts on a projct of about 15 dvloprs who had dvlopd a cod bas ovr two yars (though it was intgratd with a largr, 10-yarold cod bas). At that point, th tam dcidd to add functional tsts, bginning with th cod thy wr currntly working on, calld projct B. Thy thought it would b bst to tst with all ral objcts (rathr than mock objcts) in ordr to maximiz th tst covrag for ach functional tst. Th tam spnt a month stting up thir first functional tst. This st up includd writing a tst fixtur for ach class, which is cod that mdiats btwn a tst spcification (.g. a FIT tabl) and th appropriat objct in th systm undr tst [5]. Sinc many parts of th systm wr upstram of th cod thy wr working on, thy had to writ many fixturs bfor thy could rach th part of th systm that thy intndd to tst. Th rsult was thn whn anyon mad a cod chang upstram of projct B, all of th tsts for projct B faild and had to b updatd. Dvloprs bcam xtrmly frustratd with th burdn of tst maintnanc. On solution is to mock out parts of th systm that ar not th focus of your currnt tst. W can us mock objcts as w do with unit tsts, and for functional tsting w can also mock subsystms. Mocks man you don t hav to writ ral fixturs for vrything upstram. Similar principls ar chod in Mugridg and Cunningham s book [5], which adviss tams to avoid ovr-commitmnt to dtails that ar not ssntial to th spcific businss rul [and] focus on only on businss issu, so that it is lss vulnrabl to chang (p. 156). Functional Tsts Try and Fail to Catch Unit-Lvl Bugs If functional tsting dos not rduc th bugs found by your tsting group and customrs, th problm may b that th bugs ar at th wrong lvl for functional tsts. Solution: Unit Tsts Support Functional Tsts Functional tsts ar not a rplacmnt for unit tsts, vn if th covrag statistics look high. Unit tsts support functional tsts by xrcising th cod most likly to brak, vn if it is burid dp in othrwis inaccssibl parts of th systm undr tst. Us unit tsts for unit-lvl bugs and functional tsts for intraction bugs. Rlatd Smlls If you us functional tsts without unit tsts, you may xprinc ths smlls: It s hard to diagnos faild tsts Tst fixturs work around known issus rathr than diagnosing and fixing thm Narrativ: Pathological Functional Tsts Th prviously mntiond projct with 15 dvloprs had a clustr of thr or four classs that was rpatdly th sourc of bug rports. Th classs alrady had unit tsts, so th tam trid to rduc th

10 bug count with functional tsts. But th dvloprs writing th tst fixturs codd around th buggy classs so that thy could gt thir us cas for th functional tst don. For xampl, th dvloprs discovrd that thir fixtur had to call Sav twic to gt th objct savd proprly. Why didn t th dvloprs fix th Sav mthod? Thy xplaind that saving was only a small, initial part of thir us cas, and thir usag did not go dp nough into th cod for thm to diagnos th problm. So th bugs wr not gtting fixd. Finally, th tam assignd two dvloprs to rfactor th modul and improv its unit tst covrag. Thy quickly discovrd that th unit tsts wr inadquat bcaus thy wr som of th first unit tsts th tam had vr attmptd to writ. Aftr a month of work, th modul was cland up. It was no longr th sourc of bug rports. Th functional tst fixtur could call Sav only onc. But it was th unit tsts, not th functional tsts, that nsurd this basic functionality. Unit Tsting Complmnts Functional Tsting Unit tsts mak sur th units ar working proprly; functional tsts mak sur th units intract proprly. It is vry difficult to us a tst of intractions to improv th units thmslvs. If basic functionality is buggy, focus on rfactoring and unit tsting th individual classs. If th units ar solid but don t intract corrctly, us functional tsts. W nd both kinds of tsts. A commonly citd rason for adopting agil dvlopmnt tchniqus is th incrasd communication btwn th dvlopr and customr to rally solv th problm and us itration and fdback to com up with a good solution. Wll, unit tsting dos not addrss this issu at all and functional tsting gratly improvs this communication. Asking, Which tsting is mor important is quivalnt to asking, Ar rquirmnts quality or cod quality mor important? You cannot drop ithr you must hav both for a succssful softwar systm. With that said, lt us provid dtail on how unit tsting is mor powrful than its covrag numbrs would suggst. Unit Tsts Covr Important Cod Paths Unit tsts xrcis th most important cod paths mor asily than functional tsts can. Imagin two classs, A and B, ach with 5 cod paths, A 1 through A 5 and B 1 through B 5. Considr writing unit tsts for th two classs. A 4 and A 5 ar a gttr and sttr rspctivly, so w don t writ unit tsts for thm. W writ on tst for ach othr cod path for a total of 8 tsts. A cod path covrag mtric would tll us w hav 80% covrag. But bcaus w did whit box tsting, w know w covrd th 80% that was most likly to brak. Now considr functionally tsting th two classs. Lt s assum class A is calld bfor class B and that it s asy to st up thr of th tsts: Tst 1 xrciss A 1 followd by B 1, Tst 2 xrciss A 2 followd by B 2, and Tst 3 xrciss A 3 followd by B 3. All thr tsts incidntally xrcis th gttr A 4 and sttr A 5. With just ths thr functional tsts, w again hav 80% covrag. Unfortunatly, th functional tsts hav faild to xrcis cod paths B 4 and B 5. Ths cod paths ar triggrd by xcptional circumstancs that ar difficult to st up in a functional tst. For xampl, B 4 could dal with a division by zro that rsults whn crtain combinations of valus ar producd by class A, and B 5 could handl an xcption thrown by a rsourc. So th functional tsts 80% covrag dos not includ th cod that is most likly to brak. Instad, functional tsts tnd to focus on th main succss scnarios of th us cass. That s hlpful covrag, of cours. But it is unit tsts that frrt out th most common bugs. Furthrmor, as th cod bas grows, it bcoms hardr for functional tsts to covr cod that is many classs dp into th systm. Th functional tst has to provid th input to A that lads B to output somthing to C that causs D to throw an xcption so th tst can mak sur E handls th xcption corrctly. It s much asir to just writ a unit tst for E. Our Tsting Tool is in th Forground An immatur functional tsting tool can lad dvloprs to spnd mor tim gtting th tool to work right than thy spnd on undrstanding th domain and spcifying th tsts with customrs. Of cours, it s important that dvloprs ar traind in th functional tsting tool, and thr will b som start-up costs whn thy first start using th tool. But if th tool is th root of th problm, you will notic functional tsting smlls: It taks a long tim to writ tsts and tst fixturs; th tam spnds mor tim on fixturs than tst spcification It s hard to diagnos incorrct tst fixturs Dvloprs and customrs complain about functional tsting Solution: Don t Rbuild th Whl Us a Matur Tool W rcommnd starting functional tsting with an stablishd tool that has a track rcord of providing good fdback for customrs and dvloprs. Framwork for Intgratd Tsts, calld FIT for short, is an xampl of a widly usd tool that provids good fdback [5]. Tams may alrady hav thir own tools, of cours. But if th tool is taking ovr your tsting, you may want to rconsidr. Narrativ: Changing Tools Rcall th 15-dvlopr tam who spnt a month writing thir first functional tst. This tam was using a homgrown functional tsting tool. Th tool had a numbr of

11 advancd faturs, but it did not provid good fdback whn a tst was incorrctly spcifid or fixturizd: it was common to gt a null rfrnc xcption somwhr dp in th tool cod. Customrs simply could not diagnos th tst output. Dvloprs had to attach a dbuggr and stp through th tst. Thy spnt significantly mor tim in th dbuggr than collaborating with customrs to writ tsts. Both dvloprs and customrs complaind about working on functional tsts. This tam is now in th procss of switching to FIT. Th vry sam dvloprs who complaind about functional tsting ar now clamoring to b th first ons to try th nw tool. A good tool lts you focus on th domain and th rquirmnts; th tool itslf fads into th background [6]. If th tool is in th forground, you nd a bttr tool. 5. ARCHITECTURAL SMELLS If you ar using good tools and tchniqus and it s still hard to writ functional tsts, thn th root problm may b your systm s architctur. In particular, if your tst fixturs contain businss logic, rathr than mrly translating tst spcifications into mthod calls, thn you will want to considr th smlls blow. W also considr a smll whn it is hard for a functional tst to run through a singl, complt us cas. Functional tsts hlp push businss logic into th corrct layr (in a tird architctur) and th corrct functional modul. Whn businss logic has found its way into th wrong plac, functional tsts xpos th misplacmnt. Fixturs Contain Businss Logic to Mirror GUI Work If you find yourslf writing fixturs that must prform businss logic so that thy mirror what is don in th GUI, you may hav an architctur smll. A common caus of such duplicatd businss logic is th us of a canonical thr-tird architctur having prsntation, domain, and prsistnc layrs. Such architctur dos not always succd in kping businss logic away from th prsntation layr. In fact, it is vry common for GUIs in this stup to contain control logic. For xampl, a simpl GUI to transfr mony from on account to anothr (account1, account2) oftn dos th following in th GUI: (1) Account1.withdraw($100) (2) Account2.dposit($100) This is simpl logic, but it is businss logic and not viw logic. So, if your fixtur for th transfr(account1, account2) function has this logic in it, thn you hav cod duplication with th UI (which is bad), and you hav uncovrd businss logic in th prsntation layr (which is wors). Solution: Srvic Layr Gts Control Logic Whn you ncountr this typ of problm, th solution is to pull out th duplicat cod in a common plac. That plac is th srvic layr [1], which lis btwn th prsntation and domain layrs and contains control logic. In this way, functional tsts hlp in propr sparation of businss and prsntation logic and ncourag a nw logical layr to hold control logic. Narrativ: Building Up Fixturs For Functional Tsting This story is on from th 50-prson J2EE lasing application. As statd arlir, w introducd functional tsting aftr w had gaind xprinc with XP as an agil dvlopmnt mthodology. Building our initial functional tsts took a larg amount of work upfront bcaus w had to build a fixtur for vry singl tst. Morovr, w discovrd as w startd building ths fixturs that thr was a significant amount of businss logic that had spd into our GUI vn though w had both a domain and srvic layr. Th first dvloprs working on ths tsts had not only to build th fixturs but also to undrstand th UIs in dtail so that thy could rfactor thm and pull out all th businss logic into th srvic layr. W took two full itrations with a fiv-prson tam to do a st of larg rfactorings for th ntir prsntation layr. W thn had a dsign sssion to xplain th problm with th old ways of doing things and how thy wr not tstabl to th rst of th group. Finally, for th nxt fw itrations, whnvr somon was to writ thir first fixtur, thy would pair-program with on of th tam who did th larg rfactorings. Ovr a priod of thr to four months, w had mad svral larg rfactorings to th prsntation layr and solidifid th boundary btwn prsntation and srvic layrs. W had also rachd critical mass with th numbr of fixturs prsnt so that othr dvloprs bgan to fl comfortabl writing tst fixturs asily. Fixtur for a Modul Contains Businss Logic That Blongs in th Modul Thr is anothr way that businss logic can turn up in a tst fixtur whn a functional modul fails to contain all th businss logic that blongs in it. An xampl can bst illustrat this point. Lt us assum that on of our subsystms is a tax modul that is rsponsibl for doing all tax-rlatd calculations. Bfor introducing functional tsting, w wrot this modul and blivd w had good functional sparation. Unfortunatly, ovr th dvlopmnt of our projct not vryon using th tax modul was compltly familiar with it, so som prcalculation was mad outsid of th tax modul dpnding on spcial tax-xmpt days. This functionality should hav bn in th tax modul; in a sns, th tax modul s boundary was brachd. Whn functional tsts wr writtn for th tax modul, w would find that th fixtur cod had to prform th prcalculation that dpndd on th tax-xmpt days. At that point, a rsponsibl dvlopr would notic th duplication and rfactor th calculation into th tax modul and out of th fixtur and th non-tax-modul cod.