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. 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?

  3. Bättre hjälp för import static i Eclipse

    Sitter just nu med att bryta isär enhetstest och integrations test i ett projekt, samtidigt som jag skall öka testtäckningsgraden. Bland det jag stöter på märker jag att Eclipse har rätt kass stöd för att föreslå automatisk statisk import av metoder, såsom Assert.assertEquals och EasyMock.expect.

    En workaround är att lägga till just dessa vanliga klasser som ”favoriter”. Öppna Window > Preferences, och lägga till varje klass mha ”New Type” under Java > Editor > Content Assist > Favorites. Voila! Nu är det bara att skriva assert<ctrl+space> och man får det som man vill.

    Förhoppningsvis blir detta bättre i Eclipse med tiden – denna workaround gäller för 3.4.

  4. Junit + EasyMock

    Hittade en välskriven engelsk guide om hur man arbetar med jUnit och EasyMock. Kan rekommendera den till er som inte tidigare jobbat med EasyMock tillsammans med jUnit.

    EasyMock + jUnit guide