Metoder för att arbeta med Mock Objects

Transkript

1 Metoder för att arbeta med Mock Objects Fredrik Redgård D01, Lunds Tekniska Högskola 15 februari 2004 Sammanfattning Denna artikel är en guide till flera metoder och verktyg som finns för att arbeta med mönstret Mock Object. Den riktar sig till programmerare som är vana vid Test First, men inte har använt Mock Objects. Vi presenterar tre olika verktyg som representerar tre olika sätt att arbeta med Mock Objects. Till sist presenteras aspektorienterad programmering, och hur det kan användas för att förbättra arbetet med Mock Objects. 1

2 Innehåll 1 Introduktion 3 2 Mock Objects Atrapp Exempel med Test First Verktyg MockObjects Ramverket Exempelkod Slutsats MockMaker Genererade atrapper Plugin Slutsats EasyMock Exempelkod Slutsats Aspektorienterad vy Kort om AspectJ Intercept Creation Intercept Method Call Slutsatser 17 6 Acknowledgements 18 A MockMaker exempel 20 2

3 1 Introduktion När vi använder enhetstestning i ett system är det oftast omöjligt att skriva tester som är avgränsade. Så fort en klass når en viss nivå av komplexitet börjar den bero på andra klasser. Uppstår ett fel i någon av dessa klasser, rasar alla tester ihop, och det kan vara svårt att se vad som är fel. Lösningen är att isolera testerna med Mock Objects och göra atrapper (mock objects). Men att skiva atrapper och integrera dem i koden är inte trivialt. Komplicerade beteenden kan vara svåra att fånga i en atrapp. Klasser med väldigt många interaktioner med andra klasser leder till att vi måste skriva många atrappklasser, och en väldig massa initierings- och kontrollkod för varje test. I denna artikel presenteras de hjälpmedel och metoder för att jobba med Mock Objects som vi har undersökt. I första delen går vi igenom vad Mock Objects är, och varför det är så bra. I nästa del visar vi några verktyg som kan hjälpa till och automatisera skapandet av atrappklasser. Tredje delen handlar om hur aspektorienterad programmering kan förbättra arbetet med atrapper. 2 Mock Objects I ett system där en klass ska testas finns beroenden på andra klasser i systemet.testobjektet beror på systemets tillstånd och funktionalitet för att utföra sin egen funktionalitet. Kopplingen till systemet består av ett antal kopplings-klasser(fig.). Med Klass menar vi den klassen som ska testas, med Kopplingar menar vi de klasser som använder Systemet, och används i klassen som ska testas, och med System menar vi det tillstånd och den funktionalitet som finns utanför klassen som testas. Vi har nu ett antal negativa egenskaper: Systemets tillstånd måste initeras inför varje test, vilket kan ta lång tid. Med ett par hundra (eller tusen) tester blir det väldigt jobbigt att arbeta med Test First, då vi hela tiden ska köra alla enhetstester. En korrekt och fungerande implementation av klassen som testas garanterar inte att testerna går igenom. Om någon annan del av systemet går sönder, kan testerna krascha. Det finns delade åsikter om detta är bra eller dåligt. Men om vi ser 3

4 enhetstesterna som skiljda från funktionella tester, så ska testerna endast testa en enda klass. Om systemet har beroenden av någon utomstående resurs, som t.ex. en server någonstans, så kan det hända att testerna inte går igenom om denna resurs blir otillgänglig (servern kraschar). Enhetstesterna kan då gå igenom en gång, och nästa gång krascha. 2.1 Atrapp Kopplingen till systemet måste alltså brytas, och vi gör detta genom att införa atrappklasser för de klasser som utgör kopplingen. Dessa atrapper har ingen riktig funktionalitet, utan simulerar istället resten av systemet. Vi gör detta på följande sätt: 1. Extract Interface. Ta fram ett gränssnitt till den kopplande klassen som ska användas istället för en referens till klassen. 2. Ersätt referenser till klassen med gränssnittet 3. Låt klassen som ska testas ta emot ett objekt som implementerar gränssnittet istället för att skapa objektet själv. Vi kan nu smidigt införa en atrapp istället för den riktiga klassen när vi kör enhetstesterna. 4. Skriv en ny atrappklass som implementerar gränssnittet 5. Modifiera testerna så dessa skapar atrapperna, initerar dem, och skickar med dem till klassen som testas. 2.2 Exempel med Test First Man behöver inte bara använda Mock Objects för att förbättra tester på ett existerande system. Att använda Mock Objects tillsammans med med Test First är inte bara möjligt, utan även i många fall fördelaktigt. Som exempel ska vi visa hur man kan skriva en enkel atrapp-klass. Vår uppgift är att skriva en klass BankAccount som representerar ett bankkonto på en extern resurs (Bank). Vi börjar med att skriva tester som testar initieringen av ett konto. Ett bankkonto identifieras med kontonummer och en kod som användaren knappar in. 4

5 BankAccountTest.java: final int USER_NUMBER = 123; final int USER_CODE = 4567; final int USER_WRONG_CODE = 7654; pubic void testvalidcode() { BankAccount b = new BankAccount(USER_NUMBER, USER_CODE); public void testinvalidcode() { try { BankAccount b = new BankAccount(USER_NUMBER, USER_WRONG_CODE); fail(); catch (InvalidKeyException e) { Vi vill att BankAccount ska ansluta till banken, och kontrollera uppgifterna vi har fått. Vi har en klass SecureBankConnection som hanterar anslutningen och kommunikationen med banken. Däremot så är inte banken villig att låta oss skapa ett par testkonton och överföra pengar mellan, och ge vår ofärdiga kod full tillgång till banksystemet när vi kör enhetstesterna. Det hade dessutom gått väldigt långsamt. Vi väljer att göra en atrapp för anslutningen, och börjar med att extrahera ett gränssnitt BankConnection. Med hjälp av en atrapp testar vi BankAccount från insidan, och kan kontrollera att rätt anrop görs till anslutningen, dvs om rätt kontonummer och kod användes. Atrappen behöver för tillfället bara verifiera om ett kontonummer och en kod hör ihop. Istället för att implementera en databas med giltliga konton, simulerar vi detta istället. Vi säger till atrappen i förväg vad som kommer att hända och vad vi vill att den ska svara. Vi modifierar testerna så de använder en atrapp: public void testvalidcode() throws InvalidKeyException { MockBankConnection mock = new MockBankConnection(); mock.setexpectednumber(user_number); mock.setexpectedkey(user_code); mock.setreturnvalidate(true); BankAccount b = new BankAccount(mock, USER_NUMBER, USER_CODE); mock.verify(); public void testinvalidcode() { MockBankConnection mock = new MockBankConnection(); 5

6 mock.setexpectednumber(user_number); mock.setexpectedkey(user_wrong_code); mock.setreturnvalidate(false); try { BankAccount b = new BankAccount( mock, USER_NUMBER, USER_WRONG_CODE); fail(); catch (InvalidKeyException e) { mock.verify(); Det finns inga regler man MÅSTE följa när man skriver atrapper, men vanligvis gör man det på detta sättet. Först sätter man alla förväntade värden som kommer att användas i anrop, och alla värden man vill att atrappen ska returnera. Sist anropar man någon metod i atrappen som verifierar att alla förväntade anrop och parametrar stämde. Denna metod brukar då kasta något fel om det inte stämmer. Det är viktigt att skriva ordentliga meddelanden som visas när testet inte går igenom så att den som körde testet snabbt kan hitta orsaken och rätta till det. Genom att initiera atrappen i testfallet får vi all data samlad på en plats, och testfallet är enklare att förstå. MockBankConnection implementerar vi på följande sätt: public class MockBankConnection implements BankConnection { private int gotnbr; private int gotkey; private int expectkey; private int expectnbr; private boolean validate; /* Defined in interface BankConnection */ public boolean validateaccount(int nbr, int key) { gotnbr = nbr; gotkey = key; return validate; public void setreturnvalidate(boolean b) { validate = b; public void setexpectednumber(int nbr) { expectnbr = nbr; public void setexpectedkey(int key) { 6

7 expectkey = key; public void verify() { if (expectkey!= gotkey) { throw new AssertionError( "Expected account key was not used"); if (expectnbr!= gotnbr) { throw new AssertionError( "Expected account number was not used"); Vi har nu en väldigt klar beskrivning vad det är som BankAccount ska göra, iallafall vad gäller kontroll av kontonummer och kod, och vi kan implementera detta beteende i BankAccount: public class BankAccount { BankAccount(BankConnection b, int nbr, int code) throws InvalidKeyException { if (!b.validateaccount(nbr, code)) { throw new InvalidKeyException(); I fortsättningen när vi skriver nya tester och får en klarare bild av hr BankAccount ska fungera, är det bara att lägga in mer kontroller i MockBankConnection, och implementera resten av de metoder som är definerade i gränssnittet BankConnection 3 Verktyg För att göra livet lättare för alla Mock Object testare där ute, så finns det en hel del verktyg tillgängliga. Vi tar här upp tre olika sätt att förenkla Mock Object testning 3.1 MockObjects MockObjects[1] är ett projekt att göra atrapper av Javas standardklasser samt ett ramverk för att utvekla atrappper. Hemsidan fungerar samtidigt som en mötesplats för personer som vill diskutera Mock Objects, Test First, och andra saker Ramverket MockObjects ramverk bygger på ett interface Verifiable, som tillhandahåller en enda metod: public void verify() 7

8 verify() kastar ett AssertionFailedException om testet inte lyckades. Atrapperna implementerar denna oftast med hjälp av en verktygsklass Verifier: public void verify() { Verifier.verifyObject(this); Verifier använder Javas reflect-bibliotek till att hitta alla fält i klassen som är Verifiable, och anropar verify() på dessa. Detta gör att man enkelt kan skriva atrapper genom att hålla en lista med Verifiable objekt som håller reda på alla parametrar man vill kontrollera. Man får då gratis implementering av verify(), vilket kan vara trevligt om man har många parametrar. Om man dessutom ärver av klassen MockObject hanteras all verifiering helt och hållet automatiskt. MockObjects har ett antal klasser som implementerar Verifiable, t.ex: ExpectationValue håller reda på ett förväntat int-värde. Man sätter det värde man förväntar sig att atrappen ska anropas med, och registrerar sen vilket värde den faktiskt fick. ExpectationValue verifierar sig själv genom att kontrollera att dessa två värden är identiska. ExpectationList är en lista av förväntade värden, och fungerar nästan som ExpectationValue, förutom att man kan förvänta sig flera värden. ExpectationCounter är en verifierbar räknare. Den används mest till att räkna hur många gånger en metod har anropats, så att man kan kontrollera att detta sker rätt antal gånger. ReturnObjectList är en lista med värden som ska returneras från exemelvis en metod. Den fungerar som en enkel stack, med den extra fördelen att den går att verifiera. Den verifierar sig genom att kontrollera att det inte finns några värden kvar i stacken att returnera. ReturnObjectMap har även den en lista med värden som ska returneras, men dessa är associerade med en nyckel, så att det inte spelar någon roll i vilken ordning värdena returneras Exempelkod MockObjects styrka ligger i att arbeta med Servlets. Detta är inte så konstigt eftersom det är precis det som de flesta av utvecklarna jobbar med, och MockObjects föddes ur behovet att enkelt kunna testa dessa. Följande exempel är taget ur exempelsamlingen som kommer med MockObjects. Vi ha ett test av en Servlet som kan skicka lösenord till folk som glömt bort sitt. En Servlet är en liten bit kod som körs på en webserver och hanterar en hämtning från servern. Man kan lite kort beskriva Request-objektet som ett gränssnitt till förfrågan som exekverade denna Servlet, och Response-objektet kontrollerar svaret till web-browsern. Vi har tre stycker atrapper; mockrequest, mockresponse, och mockreminder. mockrequest och mockreminder är två av MockObjects färdiga atrapper, och mockreminder är en enkel specialskriven atrapp som simulerar själva epost-funktionen. I testet säger vi åt mockreminder att returnera ett fel att epost-adressen inte finns i registret, och vi sätter en kontroll att svaret ska vara en omdiregering till en ny adress (som förmodligen innehåller ett meddelande). 8

9 private MockHttpServletRequest mockrequest = new MockHttpServletRequest(); private MockHttpServletResponse mockresponse = new MockHttpServletResponse(); private MockPasswordReminder mockreminder = new MockPasswordReminder(); private ForgotPasswordServlet passwordservlet; public void setup() throws ServletException, IOException { passwordservlet = new ForgotPasswordServlet(mockReminder); //Sätt data som skickas till passwordservlet. //Typiskt så finns det setup* metoder som //används till att sätta de värden som ska returneras mockrequest.setupaddparameter( ForgotPasswordServlet. _PARAM, ); public void test notfound() throws ServletException, IOException { mockreminder.setup notfound(); mockreminder.setexpected address( ); mockresponse.setexpectedredirect( _not_found_uri + "? =" + ); passwordservlet.doget(mockrequest, mockresponse); mockresponse.verify(); mockreminder.verify(); Som vi ser är det kanske inte så enkel, men lättförstådd kod. Det viktiga här är att man kan se precis vad testet förväntar sig att passwordservlet ska göra: Få reda på att adressen inte är korrekt, och dirigera om användaren till en ny sida. I samband med Servlets så är det trevligt att det finns färdiga atrapper för Request- och Responseobjekten. Dessa är väldigt komplicerade saker, och det hade varit väldigt jobbigt att behöva skriva egna atrapper för dessa varje gång man ska testa en Servlet. Atrappen mockreminder är implementerad på följande vis: public class MockPasswordReminder extends MockObject implements PasswordReminder { private ExpectationValue address = new ExpectationValue("MockPasswordReminder "); private boolean notfound = false; 9

10 public void sendreminder(string an address) throws NotFoundException { address.setactual(an address); if ( notfound) { throw new NotFoundException("Not found: " + an address); public void setexpected address(string an address) { address.setexpected(an address); public void setup notfound() { notfound = true; Värt att se här är hur MockPasswordReminder använder ett ExpectationValue för att hålla reda på vilken epost-adress som skickades till klassen. Man kan även se hur klassen ärver av MockObject. Denna ärvning ger en implementation av verify() med hjälp av Verifier Slutsats MockObjects är en mycket bra start när man vill skriva egna atrapper. Det är mycket enkelt att ladda ner och installera de extra klasserna, och sen använda i sitt eget projekt. MockObjects inriktar sig på utvecklingen av Servlets, så det största antalet färdiga atrapper kommer därifrån. Men skulle det saknas en atrapp man behöver, så är det bara att skriva den och skicka in den. Ramverket för att utveckla atrapper känns väldigt trevligt att använda. Likt de hjälpsamma assert*-metoderna man får i JUnit, så är dessa extra klasser något som gör livet lite enklare när man använder sig av atrapper. 3.2 MockMaker MockMaker är ett verktyg som automatiskt genererar atrapper ur ett gränssnitt. Det är mycket lätt att använda tack vare plugins till följande utvecklingsverktyg: Eclipse[4] VisualAge JBuilder Genererade atrapper MockMaker använder verktygsklasserna från MockObjects projektet. Resultatet blir väldigt välskrivna atrapper. Med genererade atrapper tjänar man in all tid som skulle gå åt att skriva attrapper själv. Den atrapp som genereras innehåller alla tänkbara kontrollmekanismer, samt metoder för att ställa in det beteende man vill ha från atrappen. I exemplet med bankkontot hade man fått ett lite annorlunda utseende på sitt testfall: 10

11 public void testvalid() throws InvalidKeyException { MockBankConnection mock = new MockBankConnection(); mock.addexpectedvalidateaccountvalues( USER_NUMBER, USER_CODE); mock.setupvalidateaccount(true); new BankAccount(mock, USER_NUMBER, USER_CODE); mock.verify(); Fullständig listning av koden som genereras för MockBankConnection finns sist i denna artikel under avsnitt A. MockMaker producerar addexpected*-metoder för alla metoder i gränssnitet, vilka används för att visa atrappen vilka parametrar som ska användas vid anrop. setup*-metoder används för att bestämma vilka värden som ska returneras vid anrop. MockMaker genererar metoder som bestämmer att atrappen ska kasta något när en metod anropas, t.ex. setupexceptionvalidateaccount i MockBankConnection. Eftersom MockMaker genererar en atrapp ur ett gränssnitt måste man göra om denna generering varje gång gränssnittet ändras. Detta gör att man inte kan göra några ändringar i de genererade atrapperna utan att riskera att dessa ändringar går förlorade. MockMaker försöker göra så kraftfulla atrapper som möjligt, men om det skulle vara något som saknas kan det vara svårt att arbeta med Plugin I den plugin som kan användas i Eclipse lägger MockMaker in ett kommando längst ner i menyn man får upp när man högerklickar på ett gränssnitt eller klass. Det är därför väldigt lätt att arbeta med MockMaker i Eclipse, bara markera vad man vill ha en atrapp av, och så genererar MockMaker en. Det går väldigt snabbt, och ändringarna är direkt synliga i projektet Slutsats MockMaker känns väldigt smidigt att använda för att snabbt få fram en atrapp, som en automatisk version av MockObjects. Det passar väldigt bra in i arbetssättet att generera en atrapp när man tagit fram ett gränssnitt, istället för att skriva en själv. Atrapperna blir väldigt kompletta, och det kan vara lite väl stora atrapper om det bara behöver göras något enkelt. Om man vill kan man använda den genererade atrappen som en mall om man vill modifiera den. Koden är så pass enkel att man förstår vad som händer, och det är inte några större problem att ändra något. 3.3 EasyMock EasyMock[3] är en samling klasser som skapar atrapper under körning genom att läsa in en klassdefinition och simulera en atrapp. I Java kan man dynamiskt skapa en klassdefinition med hjälp av paketet java.lang.reflect [6]. EasyMock skapar en atrapp som implementerar det gemensamma gränssnittet. 11

12 3.3.1 Exempelkod De atrapper som simuleras klarar av allt som MockMakers genererade atrapper hanterar. Men eftersom man inte använder en skriven atrapp så arbetar men med en EasyMockatrapp på ett väldigt annorlunda sätt. Man använder en EasyMock-atrapp på följande sätt: 1. Skapa en atrappkontroll (MockControl) 2. Hämta det simulerade atrappobjektet 3. Spela in det beteende man vill att atrappen ska utföra 4. Anropa replay() på atrappkontrollen 5. Kör testet 6. Anropa verify() på atrappkontrollen En EasyMock-atrapp håller koll på tillstånd. Innan man kör testet definerar man de tillstånd som atrappen kommer att gå igenom under testet. Man spelar in beteende på en atrapp genom att helt enkelt utföra de anrop på atrappen som man förväntar sig att klassen som testas kommer att utföra. Med hjälp av atrappkontrollen kan man bestämma vilka värden som ska returneras i det tillstånd som atrappen är i för tillfället. Man får ett test som ser ut på följande sätt om vi använder EasyMock för att testa vårt bankkonto: public void testvalid() throws InvalidKeyException { // 1 MockControl control = MockControl.createControl(BankConnection.class); // 2 BankConnection mock = (BankConnection) control.getmock(); // 3 mock.validateaccount(user_number, USER_CODE); control.setreturnvalue(true); // 4 control.replay(); // 5 BankAccount account = new BankAccount(mock, USER_NUMBER, USER_CODE); // 6 control.verify(); Det tar lite tid att vänja sig vid att läsa denna sortens test med en atrapp. Det ser udda ut att anropa metoder på atrappen, men när man vänjer sig är det väldigt tydligt precis vilka anrop som vi förväntar oss att den testade klassen ska göra. Vi kan precis som med de övriga verktygen bestämma vilka värden som ska returneras eller undantag som ska kastas. 12

13 3.3.2 Slutsats EasyMock är väldigt svår att förstå innan man sätte sig in i hur den fungerar. EasyMock har en del trevliga egenskaper: man sparar in tiden som skulle gå åt att skiva en egen atrapp man slipper ha en stor atrapp i koden man får en kraftfull atrapp som klarar av alla kontroller vi sett man kan kontrollera ordninen av anrop 13

14 4 Aspektorienterad vy För att använda atrapper i ett projekt måste man designa den testade klassen på ett sådant sätt att man kan byta ut ett objekt mot ett Mock Object. I ett komplicerat system kan införandet av dessa element ha negativa effekter på designen, något vi vill undvika. Med aspektorienterad programmering (AOP) kan man istället väva in kod i klassen som testas, och förändrar beroendet av externa resurser när testerna körs. Med AOP modulariserar man beteenden som kan påverka flera klasser i något som kallas Aspects. En bit kod som ska köras på olika ställen i koden kallas Advice. Man kan specifiera precis var i koden dessa Advices ska exekvera genom så kallade Pointcuts. En Pointcut kan t.ex. säga att ett visst Advice ska köras före varje anrop till någon metod. När projektet kompileras så letar kompilatorn reda på alla de ställen i koden som uppfyller de krav som specifierats i den Pointcut som gäller, och lägger in koden där. Ett typiskt användningsområde är säkerhet. Varje gång något kritiskt utförs kan en bit kod som kontrollerar tillståndet köras. Istället för att manuellt klistra in sådan kod överallt man hittar kritiska operationer, så kan man specifiera ett mönster för de kritiska operationerna och låta kompilatorn sköta resten. En fördel med AOP är också att dessa moduler kan läggas till och tas bort ur den kompilerade koden enkelt genom att säga vilka aspekter som ska kompileras in. I de följande exemplen på hur man kan använda AOP för att förenkla och förbättra användandet av atrapper, kommer vi bara använda relativt enkla kodfragment för att illustrera. 4.1 Kort om AspectJ I de exempel som följer använder vi oss av AspectJ som är en aspektorienterad preprocessor och kompilator för Java. Syntaxen är lite kryptisk att sätta sig in i från början, så vi går bara igenom en liten del av syntaxen här för att kodfragmenten ska gå att förstå. En aspekt är som en klass på många sätt, den kan t.ex. ha sin egen.java-fil eller vara nästlad i en annan klass. En aspekt defineras på följande sätt: aspect MyAspect { //contents Man kan sen i aspekten definera en Pointcut som ska användas. Syntaxen för detta är rätt advancerad och det väldigt mycket man kan göra, så vi visar bara en del enkla smakprov. pointcut pc(): call(public int SomeClass.Method(int)); pointcut pc2(): call(* SomeClass.*(..)); pointcut pc3(): pc2() && cflow(execution(* *.test*())); pc() identifierar alla punkter i koden som anropar Method(int) i klassen SomeClass, medan pc2() med hjälp av asterisker matchar alla metoder i klassen SomeClass. (..) betyder att alla parametrar matchas. pc3() använder alla de punkter pc2() identifierar, men kräver dessutom att vi är i exekveringsflödet av någon metod som börjar med test, dvs vi håller på att exekvera ett test. 14

15 I våra exempel som följer använder vi bara advice av typen around. Denna typen av advice körs runt någon annan kod, och kan manipulera exekveringen och resultatet av ett anrop. Med hjälp av ett around advice, kan vi förhindra ett anrop, och istället returnera vilket värde vi vill. int around() : pc() { return 7; Detta förhindrar alla anrop till Method, och returnerar alltid 7. Vi ska nu visa några sätt att använda atrapper med AOP. 4.2 Intercept Creation När man använder sig av atrapper kan man oftast undvika att objekt av den mockade typen skapas i en metod man vill testa genom att skicka med ett färdigt objekt. Men ibland behöver man skapa sådana objekt i metoden, och för att kunna ersätta dessa med atrapper måste man intoducera en extern fabrik för dessa som kan förändras vid testningen. Detta är dels svårt att kontrollera att det används rätt, samt kan påverka designen negativt. Istället kan man med AOP låta metoden skapa objekten på vanlig vis, och väva in en bit kod som istället använder atrapper: public aspect InterceptCreation { public static ArrayList objects = new ArrayList(); pointcut atnew(): call( SomeClass.new(..) ) && cflow(execution(* *.test*())) SomeClass around() : atnew() { MockSomeClass mock = new MockSomeClass(); objects.add(mock); return mock; Vi definerar atnew() att betyda anrop till konstruktorn till SomeClass, när vi är under ett anrop till en metod som börjar på test. Det som händer är att varje gång ett objekt av SomeClass skapas så kommer denna biten kod in och ändrar så att det skapas ett objekt av typen MockSomeClass. Effekten blir att vi utan att ändra någon kod i den testade klassen har ersatt alla nya instanser av SomeClass till MockSomeClass. Fördelar med denna lösning: Använder en vanlig atrapp Våra tester påverkas inte så mycket jämfört med att använda en atrapp på vanligt sätt Påverkar inte designen när vi vill använda en atrapp 15

16 Nackdelar: Kan inte styra atrappen Ett annat alternativ är att använda en enda atrapp till alla skapade objekt: public aspect InterceptCreation { public static MockSomeClass replace; pointcut atnew(): call( SomeClass.new(..) ) && cflow(execution(* *.test*())) SomeClass around() : atnew() { return replace;... public void testsomething() { MockSomeClass mock = new MockSomeClass(); InterceptCreation.replace = mock; TestedClass tc = new TestedClass(); tc.dosomething(); mock.verify(); Fördelar med denna lösning: När det handlar om en enkel operation som ska utföras på flera olika objekt är det lätt att räkna ihop de metoder som anropas och avgöra om testet lyckades Man kan styra atrappen i testfallet, vilket ger samlad och kod som är lätt att förstå Nackdelar: Om de olika objekten som vi ersätter med atrapper ska ha väldigt olika beteenden (genom parametrar i konstruktorn t.ex.), blir atrappen vi ersätter de med komplicerad 4.3 Intercept Method Call I enkla fall är det onödigt att skapa en helt ny klass för att göra en atrapp. Det kan t.ex. bara vara en enkel metod som ska förändras. Det kan då vara användbart att väva in kod som förändrar ett par enskilda metoders beteende. public aspect InterceptMethod { pointcut atmethod(): 16

17 call(public int SomeClass.getValue()) && cflow(execution(* *.test*())) int around() : atmethod() { return INVALID_VALUE; Fördelarna med denna lösning är: Man slipper använda interface för att skriva en atrapp helt och hållet Man kan förändra beteendet på en av metoderna i den klassen som ska testas Nackdelar: Det kan lätt bli mycket spridd aspekt-kod som hanterar enskilda metoder Man täcker inte en hel klass. Det finns inga försäkringar för att man inte har missat någon metod Detta kan även kombineras med Self Shunt, vilket är en variant av Mock Object där man använder test-klassen som atrapp. private static aspect InterceptMethod { pointcut atmethod(): call(public int SomeClass.getValue()) && cflow(execution(* *.test*())) int around() : atmethod() { return mockgetvalue(); int mockgetvalue() { return INVALID_VALUE; public void testsomething() { //... Fördelar: Vi kan ändra en enda metod på ett väldigt enkelt sätt, och ge den ett nytt beteende 5 Slutsatser Att arbeta med Mock Objects kan vara väldigt belönande. Man får bland annat: Avgränsade tester. Man kan utveckla en klass utan att oroa sig över att resten av systemet fungerar. 17

18 Oberoende utveckling. Man behöver inte ha resten av systemet på plats för att utveckla klassen. Genom att bygga atrapper som simulerar interaktion med resten av systemet kan man koncentrera sig på att utveckla en klass åt gången. Interface Discovery. Ett väldigt bra sätt att designa anslutna klasser är att först göra atrappobjekt och genom att skriva simuleringen av systemet i dessa utforska hur resten av systemet ska se ut. Med hjälp av verktyg som automatiserar tillverkningen av atrappobjekt ur interface eller färdiga klasser sparar man tid som kan användas till bättre saker. De verktyg som finns att använda har ofta dessutom ett ramverk som ger möjligheter att skriva kraftfulla atrapper på ett enkelt sätt. Dessutom är det inte samma risk att skriva trasiga atrapper, och på det sättet få ett defekt system. Vi har visat hur AOP kan vara värdefull i komplexa interaktionsmiljöer, och i system där man vill införa atrapper i ett existerande system, med så lite påverkan av designen som möjligt. Aspektorienterade verktyg kan samla kod som har med Mock Objects i en modul som inte behöver kompileras med i produktionskoden. En fortsättning av denna sammanställningen kan vara att gå djupare in på vad de olika verktygen kan bidra med, och hur dessa jämförs med varandra. Aspektorienterade atrapper behöver studeras närmare vad gäller hur den extra komplexiteten i test-klasserna påverkar arbetet, och om det finns något bättre aspektorienterat sätt att testa klasser på. För den som är mer intreserad av enhetstestning med AspectJ finns en bra artikel som heter Virtual Mock Objects using AspectJ with JUNIT [5]. Denna artikel beskriver ett ramverk i AspectJ för att simulera atrapper utan att använda skrivna atrapper eller verktyg. 6 Acknowledgements Jag vill tacka alla som granskat denna artikel och bidragit med tips om förbättringar. Jag vill speciellt här tacka Gregor Brunmar som korrekturläste detta, och bidrog med ett perspektiv på innehållet. Jag vill tacka Görel Hedin som försåg mig med all tryckt litteratur jag använt. 18

19 Referenser [1] MockObjects [2] MockMaker WebHome [3] EasyMock Home http// [4] Eclipse Project [5] Virtual Mock Objects using AspectJ with JUNIT, Simon Monk, Lancaster University, UK Stephen Hall, Bluecrest Consultancy Ltd, UK [6] Java 2 Platform SE v

20 A MockMaker exempel public class MockBankConnection implements BankConnection { private ExpectationCounter myvalidateaccountcalls = new ExpectationCounter("BankConnection ValidateAccountCalls"); private ReturnValues myactualvalidateaccountreturnvalues = new ReturnValues(false); private ExpectationList myvalidateaccountparameter0values = new ExpectationList("BankConnection int"); private ExpectationList myvalidateaccountparameter1values = new ExpectationList("BankConnection int"); public void setexpectedvalidateaccountcalls(int calls) { myvalidateaccountcalls.setexpected(calls); public void addexpectedvalidateaccountvalues( int arg0, int arg1) { myvalidateaccountparameter0values.addexpected( new Integer(arg0)); myvalidateaccountparameter1values.addexpected( new Integer(arg1)); public boolean validateaccount(int arg0, int arg1) { myvalidateaccountcalls.inc(); myvalidateaccountparameter0values.addactual( new Integer(arg0)); myvalidateaccountparameter1values.addactual( new Integer(arg1)); Object nextreturnvalue = myactualvalidateaccountreturnvalues.getnext(); if (nextreturnvalue instanceof ExceptionalReturnValue && ((ExceptionalReturnValue) nextreturnvalue).getexception() instanceof RuntimeException) throw (RuntimeException) ((ExceptionalReturnValue) nextreturnvalue).getexception(); return ((Boolean) nextreturnvalue).booleanvalue(); public void setupexceptionvalidateaccount(throwable arg) { myactualvalidateaccountreturnvalues.add( new ExceptionalReturnValue(arg)); public void setupvalidateaccount(boolean arg) { myactualvalidateaccountreturnvalues.add( new Boolean(arg)); public void verify() { myvalidateaccountcalls.verify(); myvalidateaccountparameter0values.verify(); 20

21 myvalidateaccountparameter1values.verify(); 21