1. final new static mock

    Jag måste säga det – Mockito smakar väldigt bra. Tidigare använde jag EasyMock och jMock och idag läste jag mig in på JMockit, som skriver:

    Design considerations for production code

    The problem with imposing restrictions on the design of production code is that there are good reasons for making classes final, for directly obtaining instances of collaborators with the new operator, and for using APIs based on static methods. There is nothing inherently wrong with using these three Java language keywords, after all.

    Fine. Jag kan köpa det. Men sedan går man vidare och säger

    The JMockit mocking API is simple, consistent, and minimal.

    Nu börjar det bli jobbigt att hålla med :) Låt oss ta deras exempelkod:

       public void testDoOperationAbc(final DependencyXyz mock)
       {
          new NonStrictExpectations()
          {
             AnotherDependency anotherMock;
    
             { anotherMock.doSomething("test"); result = 123; }
          };
    
          new ServiceAbc().doOperation("some data");
    
          new Verifications()
          {{
             mock.complexOperation(true, anyInt, null); times = 1;
          }};
       }

    och så jämför vi med samma sak i Mockito:

        public void testDoOperationAbc(final DependencyXYZ mock) {
            when(anotherMock.doSomething("test")).thenReturn(123);
            new ServiceAbc().doOperation("some data");
            verify(mock.complexOperation(eq(true), anyInt(), eq(null)));
        }

    eller BDD-style:

        public void doOperationCallsComplexOperation(final DependencyXYZ mock) {
            // GIVEN
            given(anotherMock.doSomething("test")).willReturn(123);
    
            // WHEN
            new ServiceAbc().doOperation("some data");
    
            // THEN
            verify(mock.complexOperation(eq(true), anyInt(), eq(null)));
        }

    I min värld är Mockito det mockningsramverk som är minst i vägen. För nyskriven kod vet jag vad mitt val faller på. Det är inte lika ”komplett” eller kraftfullt som andra ramverk, men så är det också inte i vägen. Måste man prompt använda final och static eller mocka privata metoder kan PowerMock hjälpa till.

  2. Bra verktyg för dåliga test?

    Jag sprang idag över denna demo av SpryTest – ett verktyg med vilket man kan få hjälp att skriva test som masserar legacy code (dvs kod som inte täcks av test). Nej, jag ser verkligen inte detta som en silver bullet och är tveksam till att använda det över huvud taget.

    (Läs mer…)

  3. När ska man mocka?

    Där jag jobbar nu mockar jag ungefär en gång i veckan. Nästa vecka kör vi vårens fjärde möte i JDojo@Gbg och temat för denna gång är just mockning. Vi kommer använda Mockito som jag tycker är mer lättanvänt verktyg än t ex EasyMock. En fråga som alltid dyker upp efter att man petat lite på ämnet brukar vara ”Vad är skillnaden mellan en stub och en mock?” I Mocks Aren’t Stubs har Fowler summerat det ganska bra tycker jag:

    • Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
    • Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).
    • Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it ’sent’, or maybe only how many messages it ’sent’.
    • Mocks are [...] objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

    Mockist Approach vs Stubborn Approach

    Detta är ett känsligt ämne – att påstå något om något som någon identifierar sitt arbete med. Jag brukar hävda att med stubborn approach (dvs när man bygger stubs eller fakes för sina collaborators/samarbetsklasser) så tenderar man att tappa fokus när man flyttar sin testverksamhet mellan olika klasser. Att använda en Mockist Approach (dvs när man mockar samarbetsklasserna runt sin ”enhet under test”) skulle på så sätt kunna hjälpa till att bibehålla fokus på den klass man utvecklar.

    Detta påstående brukar väcka lagom mycket anstöt för att få igång en givande konstruktiv diskussion där erfarenheter delas mellan debatörrer. Vad betyder det t ex när ett test med ett mockat beteende fallerar, jämfört med att använda en stub som kanske kan vara den verkliga (enda) implementationen?

  4. Walking Skeleton

    Under paneldebatten på SDC2010 fick jag lära mig ett nytt uttryck som jag tycker är så illustrativt och användbart att det förtjänar ett eget blogginlägg, nämligen Walking Skeleton. Till min glädje upptäckte jag att boken jag håller på att läsa, Growing Object-Oriented Software, Guided by Tests använder och beskriver detta begrepp ingående.

    Walking Skeleton syftar på att man bör skapa en fungerande infrastruktur innan man kan komma igång med den testdrivna cykeln. Ett Walking Skeleton är en implementation av den tunnaste möjliga skivan av riktig funktionalitet som vi kan bygga automatiskt, driftsätta automatiskt och testa ”end to end”.
    (Läs mer…)

  5. Delta i undersökning om effektivitet inom testning

    CITCON-listan är mottagare denna gång av en inbjudan från Tanjila Kanij vid Swinburne University of Technology, där man ber om deltagande genom en webbenkät som skall ta knappt 25 minuter att fylla i.

    ”[we are] conducting a survey to find out the key factors that influence the performance of software testers”

    Om du känner dig träffad (eller känner någon som borde känna sig träffad) så är URL:en till webbenkäten http://benambra.org/survey/

  6. Ny version av TextTest med utökad Java stöd

    TextTest är en verktyg för att stödja arbetssättet ”Text-based Testing”, som är en alternativ till klassiskt enhetstestning med t.ex. JUnit. Det nyligen kom en ny version av denna verktyg, 3.17, som har bättre stöd för Java än tidigare versioner. (Läs mer…)

  7. Programmering är enbart Design

    Har du eller någon du känner någonsin försökt jämställa mjukvarubranschen med byggbranschen? Visst är det väl så att vi, precis som dem, bygger saker och då borde arbetssätt och metodik vara densamma? Eller?

    Jag tänker här lämna över ordet till Joakim Holm som har skrivit ett underbart blogginlägg som öppnar ögonen på en:

    Programming Is All Design

    http://jockeholm.wordpress.com/2010/01/29/programming-is-all-design/Programm
  8. Cfp: Agile Testing Days

    Det skapas mer och mer tjänster och material kring agila utvecklingsmetodiker och tekniker. Jag sprang på (eller blev översprungen av) Agile Record. som planerar att ge ut en PDF-tidning fyra gånger per år. Den första ligger ute nu (kostar din e-postadress) och ser tidningsaktig ut (inte hunnit läsa ännu dock).

    Därifrån såg jag hur som helst att Agile Testing Days nu har öppnat sin call for papers. Så om du fick nobben från SDC eller om den inte ger nog med agil eftersmak i munnen kanske en konferens i Berlin lockar.

    Ett nytt ”Agile Community” har också startats, behövs det? Kanske det, liksom Scrum on Rails.

  9. Studie om testdriven utveckling

    Emellanåt ställs frågan om det påvisats att testdriven utveckling verkligen kan ge några konkreta, positiva resultat utanför skolprojekt, dvs i industrin. ”Ja, men det finns inte jättemånga som jag känner till”, är det svar jag brukar ge. IBM och Microsoft har publicerat en studie där man sett att TDD minskat antalet buggar med mellan 40 och 90 procent. De skriver:

    Test-driven development (TDD) is a software development practice that has been used sporadically for decades. [...] However, little empirical evidence supports or refutes the utility of this practice in an industrial context. Case studies were conducted with three development teams at Microsoft and one at IBM that have adopted TDD. The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.

    På tisdag kör vi igång en ny omgång av JDojo där vi genom övningar övar upp TDD-färdigheterna. Utöver JDojon  kommer vi också i vår genomföra motsvarande koncept ute hos kund i deras lokaler.

  10. XPDay London har startat

    Årets upplaga av XPDay har dragit igång och Gojko Adzic är inte sen att blogga om detta. Måste säga att det är intressant att Google byggt verktyg som utvärderar test, genom att titta på om ett fallerande test ledde till att kod ändrades eller lades till – vilket är bra – eller om testet i sig ändrades – vilket är dåligt (bl a pga underhållskostnader). Ca 100 miljoner dollar läggs årligen på automatisering av test och det finns potential att spara in 160 miljoner om buggar kan upptäckas tidigare i utvecklingscykeln, enligt Gojkos återrapportering.

    Konferensen hålls i två dagar där hela den andra dagens program utgörs av Open Space.

  11. Undersökning om agil utveckling

    VersionOne ligger bakom en undersökning som de kallar State of Agile Development (2008). Jag vet inte hur de gjort sitt urval för vilka som får delta, men jag tyckte att det var intressant att se vad VersionOne anser vara agila delar/komponenter/kännetecken. Se t ex denna lista:
    (Läs mer…)

  12. När Open Source är vackert

    CITCON diskuterades byggmiljöer och bland produkterna fanns givetvis Hudson, eller ”[the] nuclear plant” som en branschkollega i Göteborg så fint titulerade det :) Godsaken här är detta e-mail som skickades till citcon-mailinglistan, en knapp vecka efter konferensen avslutats:

    (Läs mer…)

  13. IvyBeans

    Ivy logo

    För de som vill börja använda Ivy för att hantera beroenden i sina NetBeansprojekt så hittade jag häromdagen en trevlig plugin vid namn IvyBeans som förenklar processen.

    IvyBeans

  14. Continuous Integration-konferens startar i Paris

    Alldeles nu startar årets upplaga av Continuous Integration and Testing Conference Europe. Deras mailinglista har jag tipsat om tidigare och den har prenumeranter som är riktigt kompetenta får jag säga (annat är det med t e x JUnit-listan som bara handlar om ”what shoud I test – this is my class:”).

    För oss som inte har möjlighet att delta finns alltid twitter, även om det givetvis inte ger samma chans till delaktighet och erfarenhetsutbyte vid Open Space-sessionerna. Konferensen är för övrigt ”gratis” – dvs ingen avgift och ingen (Läs mer…)

  15. Resurser, inte funktioner

    Jag vet att den här insikten förmodligen beror på att jag förläst mig alldeles för mycket om REST, men jag kan inte göra mig av med känslan av vi, systemutvecklarna, lägger ner för mycket krut på fel problem.

    (Läs mer…)

Nästa sida