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. Kort om FOSDEM10

    FOSDEM är stort. Mängder med folk trängs på en liten yta och varannan människa är expert på XMPP, PosgreSQL, SIP, Gnome, Mozillas byggmiljö, hur dålig Javas type inference är … Här kommer halvt uppstädade anteckningar, i väntat på att presentationerna läggs ut.

    Groovy

    Luca höll en väldigt enkel introduktion till Groovy (med tanke på den extremt kunniga publiken i Free Java-rummet). Min behållning var att se hur Groovys closure syntax ser ut, t ex såhär:

    alist = ['hej','på','dej']
    alist.sort{ element ->
     element[-1]
    }
    // sorterar på sista bokstaven i varje element
    // (en sträng hanteras som en lista av tecken, precis som i Python t ex)
    
    20.times { attr ->
     println("This is iteration ${attr}")
    }
    // man verkar använda särskilda metoder som tar closure som argument
    
    alist = alist.collect{ el ->
     el + "\o/"
    }
    // finns grep också
    println al

    Efterföljande presentation i samma rum (Free Java) började med att säga ”So, I know a way to make Groovy closures work at least 20 times faster” :)

    Lamba + JSR 292

    Genast åkte kompetensnivån upp i taket – precis som tidigare år. Har man inte koll på hur JVM:en egentligen fungerar (eller iaf har läst Java Lang Specen), och kan läsa det jad eller annan dekompilator spottar ur sig så börjar man känna sig utanför. Inte pga tonen mellan folk (Javafolk är i allmänhet tvärtom väldigt trevliga och ödmjuka), utan helt enkelt pga att det är på den nivån som många argumenten ligger (om inte rent av de flesta).

    Remi gick iaf igenom förslagen för hur lambda kan komma att implementeras, både vad gäller syntax, scope-frågan och även hur det skulle kunna implementeras i språket.

  4. WikiMedia får ett lyft – äntligen

    All heder åt wikis, men varför finns ingen wiki som hängt med i web 2.0-teknikväxlingen? Nu har äntligen både WikiMedia (motorn) och WikiPedia fått sig ett litet lyft men jag saknar ännu den wiki där man gränslöst växlar mellan läsnings- och redigeringsläge. På en företagswiki är man troligtvis i 90 % av tiden ute efter att läsa. Att göra småjusteringare (fixa sökvägar, typos, lägga till en länk till något närbesläktat) borde verkligen inte kräva att man skall lära sig en ny syntax, vänta på att sidan laddar om, välja preview, och sedan spara sidan – cykeln är helt enkelt för lång och för mycket ”i vägen”.

    (Läs mer…)

  5. Google Native Client SDK Preview

    En preview av google’s native client SDK finns nu att ladda ner. Native Client SDK ger dig möjligheten att skriva dina web applikationer i C/C++. Binärfilerna körs inte i en virituell maskin men innan dom exekveras så verifieras så att dom bara innehåller dom instruktioner som är tillåtna samt ser till vilket minne som skall vara tillgängligt för applikationen. Detta öppnar upp för möjligheten kunna exekvera kod i en web läsare med lika bra prestanda som om det vore en lokal native applikation. Det blir också lättare att porta existerande applikationer till web applikationer.

    Läs mer här och titta på denna video som berättar lite om NaCl och dess möjligheter.

  6. Borde Flash överges?

    IE6 har äntligen gått i graven, amen! (Tas till och med upp i Tech Radar från Thoughworks!) Hur är det då med Flash?

    Nu när vi har HTML5, video, canvas, geoloc, animationer och kraftfullt CSS (även om det borde vara mer objektorienterat som tidigare diskuterat av bl a Nicole Sullivan) kan man fråga sig om Flash kommer överleva, eller kanske varför det skulle få stanna kvar. Steve Jobs bloggar sällan men har i 1700 ord gett sig på Adobes Flash och han hävdar att deras sandbox är ett problem (läs Techcrunchs sammanfattning)

    Jag gissar att det är just pga denna sandbox som Flash inte kommer dö ut. Tänk bara all reklam som cirkulerar på världens webb. Vem vill släppa lös ett JavaScript-monster som petar på hela DOMen och springer runt och skräpar ner på sin sida, bara för att man vill tjäna pengar genom reklam? Jag gissar att reklamfinansierad media älskar Flash pga att det kommer i någon form av sandlåda som är begränsad till de pixlar de får.