Det finns redan mängder med tutorials över hur man sätter upp Google-konton på sin iPhone men jag har upplevt det aningen problematiskt att synka multipla Google-kalendrar och tänker mig att detta inlägg får fungera som en steg för steg-guide över hur jag fick till synkningen. Jag har en iPhone 3GS med iOS 5 och använder mig av Google Sync för synkronisering.

Har du inte redan satt upp ett Google-konto på din iPhone följer du dessa steg:

1. Under inställningsmenyn på din iPhone väljer du E-post, kontakter, kalendrar
2. Lägg till konto
3. Välj att skapa ett Microsoft Exchange-konto (vilket är det protokoll Google Sync använder vid synkronisering till iPhone)

4. Under E-post fyller du i din fullständiga e-postadress
5. Lämna domänfältet tomt
6. Fyll i din fullständiga e-postadress under Användarnamn
7. Skriv in lösenordet för ditt Google-konto
8. Klicka på Nästa
9. När fältet Server poppar upp fyller du i m.google.com
10. Klicka på Nästa
11. Välj vad du vill synka (denna guide kräver att du åtminstone väljer att synka kalendrar)

Setup av synkroniseringen är nu klar och beroende på vad du i steg 11 valde att synka kommer det nu att pushas ut information till din iPhone.

Med Google Sync kan du synka upp till 25 kalendrar på din iPhone vilket man enkelt ska kunna sätta upp genom att surfa in på http://m.google.com/sync och logga in på sitt konto. Här stötte jag dock på problem. Sidan talade om för mig att Google Sync tyvärr inte kunde stödja min enhet eftersom jag var tvungen att ha iOS 3 eller senare – något som jag uppenbarligen hade då jag precis uppdaterat till iOS 5.

Efter en tids undersökning kunde jag konstatera att detta var en bugg fler användare upplevt och en konsekvens av att Google Sync befinner sig i ett beta-stadie. Sajten kräver att sidan presenteras på engelska och det du behöver göra för att komma runt problemet är att byta språk från svenska till just engelska enligt nedan steg:

12. Med din iPhone, surfa in på http://m.google.com/sync
13. För att ändra språk klickar du på länken Byt språk (jag valde English (UK))
14. Sidan laddas om och du har nu möjlighet att logga in. Gör detta genom att klicka på Sign in with your Google Account
15. Du möts nu av de enheter du har satt upp ditt Google-konto på och genom att klicka dig in på de olika enheterna kan du välja exakt vilka kalendrar du vill synka

16. Efter att ha valt vilka kalendrar du vill synka och klickat på Save är du klar

När du nu lägger till, editerar eller tar bort händelser i dina kalendrar kommer dessa speglas på alla enheter du synkat enligt ovan steg – detta gäller självfallet oberoende av om du gör förändringarna i kalendern på din iPhone eller i webbgränssnittet på din dator.

package se.cygni.blog;

import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;

import javax.persistence.EntityManager;

import org.junit.Before;
import org.junit.Test;

public class BlogServiceTest {

    private BlogService service;
    private EntityManager entityManager;

    @Before
    public void setup() {
        entityManager = mock(EntityManager.class);
        service = new BlogService(entityManager);
    }

    @Test
    public void addEntry() {
        Entry entry = new Entry("title", "text");

        service.addEntry(entry);

        verify(entityManager).persist(entry);
    }

}

Testet i exemplet är relativt enkelt och verifierar endast att persist anropas i addEntry och ger oss följande kod för ett Spring-baserat projekt:

package se.cygni.blog;

import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;

import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class BlogService {

    @PersistenceContext
    private EntityManager entityManager;

    public BlogService() {
    }

    protected BlogService(EntityManager entityManager) {
        this.entityManager = entityManager;
    }

    @Transactional
    public void addEntry(Entry entry) {
        entityManager.persist(entry);
    }

}

För att kunna använda en mockad entityManager har vi lagt till en konstruktor som tar en EntityManager som BlogService sedan kan använda. Använder vi dessutom ”field injection” är vi tvugna att lägga till en no-args-konstruktor. Alternativt hade vi kunnat lägga till en setter istället.

    protected void setEntityManager(EntityManager entityManager) {
        this.entityManager = entityManager;
    }

Det är väl antagligen inte så illa att behöva lägga till konstruktorer alternativt setters även om det blir värre när en klass har flera beroenden. Däremot känns det ju lite onödigt när både Spring och Java EE numera stödjer field injection. Det går ju att köra enhetstesterna med till exempel Spring och låta Spring injicera alla beroenden. Detta anses dock inte helt lämpligt för enhetstester utan lämpar sig bättre för integrationstester. Istället kan Mockito ta hand om injicering, genom att köra testerna med MockitoJUnitRunner och använda annotationerna @Mock och @InjectMocks. Mockito fungerar då i princip som en enkel IOC-container och några extra konstruktorer eller setters behövs inte.

package se.cygni.blog;

import static org.mockito.Mockito.verify;

import javax.persistence.EntityManager;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.runners.MockitoJUnitRunner;

@RunWith(MockitoJUnitRunner.class)
public class BlogServiceTest {

    @Mock
    private EntityManager entityManager;

    @InjectMocks
    private BlogService service = new BlogService();

    @Test
    public void addEntry() {
        Entry entry = new Entry("title", "text");

        service.addEntry(entry);

        verify(entityManager).persist(entry);
    }
}

@Controller
public class MyController {

    @EJB(mappedName="java:module/MyService")
    private MyService myService;

    @RequestMapping(value = "/", method = RequestMethod.GET)
    public String home(Model model) {
        model.addAttribute("message", myService.getMessage());
        return "home";
    }
}

Nyckeln till att injektionen med @EJB-annotation fungerar, i exemplet ovan, är att mappedName används. Spring utför då en JNDI-lookup på det angivna JNDI-namnet. Eftersom JNDI har standardiserats i Java EE 6 är dessutom namnen portabla mellan applikationsservrar. Stödet för Java EE 6 kommer säkerligen förbättras i framtida versioner av Spring så det finns bra defaults för ejb-lookups med JNDI.

En annan spännande detalj med detta exempel är att MyService inte behöver vara ett interface eftersom Java EE 6 inte kräver detta för lokala session beans. Dessutom kan session beans paketeras tillsammans med resten av webbapplikationen i war-arkivet. D.v.s. det behövs ingen ejb-jar och inget EAR-arkiv.

Läs hela artikeln på Java Code Geeks.

• Roberts inlägg om kortkommandon och handgrepp är alltid högaktuellt. Inlägget visar bland annat på smarta kommandon för navigering och refactoring.
• Save Actions är ett ovärderligt verktyg om du vill hålla ordning och reda i koden.
• Conditional Breakpoints och Exception Breakpoints kan vara välbehövligt i vissa debugsituationer.

Kolla även in en rad tips på olika smarta plugins, hur man remote-debuggar osv.

@NotNull
@Size(min = 5, max = 20)
@Pattern(regexp = "[a-zA-Z0-9\\._-]+")
private String userName;

Bean Validation är inte knutet till något speciellt ramverk eller lager. Det finns däremot bra stöd för Bean Validation i flertalet populära ramverk, såsom Hibernate och JSF 2. Dessutom är det enkelt att utföra validering via API:t:

import javax.validation.ConstraintViolation;
import javax.validation.Validation;
import javax.validation.Validator;
import javax.validation.ValidatorFactory;
...
ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
Validator validator = factory.getValidator();
Set<ConstraintViolation<Customer>> constraintViolations = validator.validate(customer);

För att komma igång med ett Bean Validation (Hibernate Validator 4.x är referensimplementationen) i ett Maven-projekt lägg till följande beroenden i din pom:

<dependency>
 <groupId>org.hibernate</groupId>
 <artifactId>hibernate-validator</artifactId>
 <version>4.2.0.Final</version>
</dependency>
<dependency>
 <groupId>org.slf4j</groupId>
 <artifactId>slf4j-jdk14</artifactId>
 <version>1.6.1</version>
</dependency>

Används Hibernate eller JSF 2 räcker det oftast med att lägga till ovanstående beroenden så länge de finns tillgängliga i applikationens class path. Används JSF 2 går det till exempel att aktivera validering för ett inmatningsfält på följande sätt:

<h:inputText value="#{customer.age}">
  <f:validateBean/>
</h:inputText>

Bean validation stödjer dessutom validering av grupper som gör det möjligt att validera olika aspekter av ett objekt:

@Min(value=15, groups=AgeCheck.class)
private int age;

Första steget är att lyfta in Scalas API, JUnit 4 (om du inte redan kör det) och ett testramverk. Jag tänkte använda ScalaTest. För att göra det så lägger vi till följande beroende i pom.xml

<dependency>
    <groupId>org.scala-lang</groupId>
    <artifactId>scala-library</artifactId>
    <version>2.9.1</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.8.1</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.scalatest</groupId>
    <artifactId>scalatest_2.9.1</artifactId>
    <version>1.6.1</version>
    <scope>test</scope>
</dependency>

Sedan behöver vi säga till Maven att också kompilera och köra testfall som ligger i biblioteket src/test/scala, så då lägger vi till tre plugins.

maven-scala-plugin ansvarar för att kompilera scalakoden till bytekod.

<plugin>
    <groupId>org.scala-tools</groupId>
    <artifactId>maven-scala-plugin</artifactId>
    <version>2.15.0</version>
    <executions>
        <execution>
            <goals>
                <goal>testCompile</goal>
            </goals>
            <configuration>
                <args>
                    <arg>-make:transitivenocp</arg>
                    <arg>-dependencyfile</arg>
                    <arg>${project.build.directory}/.scala_dependencies</arg>
                </args>
            </configuration>
        </execution>
    </executions>
</plugin>

maven-surefire-plugin är den som kör testerna – om du redan har tester i projektet så har du redan lagt till den här pluginen och behöver då bara utöka den att också inkludera filer som heter **/*Spec.*.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.6</version>
    <configuration>
        <useFile>false</useFile>
        <disableXmlReport>true</disableXmlReport>
        <includes>
            <include>**/*Spec.*</include>
            <!-- För att hantera existerande tester -->
            <include>**/*Test.*</include>
        </includes>
    </configuration>
</plugin>

build-helper-maven-plugin lägger till källkodsmappar till kompilering, eftersom Maven från början bara hanterar en källkodsmapp för implementationskod (src/main/java som standard) och en för test (src/test/java som standard).

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>build-helper-maven-plugin</artifactId>
    <executions>
        <execution>
            <id>generate-test-sources</id>
            <phase>generate-test-sources</phase>
            <goals>
                <goal>add-test-source</goal>
            </goals>
            <configuration>
                <sources>
                    <source>src/test/scala</source>
                </sources>
            </configuration>
        </execution>
    </executions>
</plugin>

Ok, nu behöver vi bara skapa mappen src/test/scala och sedan kan du börja koda!

Om du vill kan du stanna här. Nu kan du skriva testklasser i Scala, annotera metoderna med JUnits @Test och köra på som vanligt. Det du vinner är att du får tillgång till Scalas syntax och konstruktioner och att du kan lära dig i en bekant miljö.

Det andra alternativet är att du också börjar titta på vad Scalas testramverk kan erbjuda. I grunden är det inte så stor skillnad, men rent syntatiskt och kanske också tankemässigt så är det lite annorlunda. ScalaTest har stöd för BDD – Behaviour Driven Development. Tanken är att varje test är en beskrivning av en funktion/ett beteende som en roll skall uppfylla. Rollen tar sedan formen av en eller möjligtvis flera klasser. Tack vare att Scalas syntax går att det skriva ganska koncisa specifikationer, nästan som rena texttester för att beskriva beteendet som förväntas.

Vi börjar med att skriva en första specifikation, som vår applikation skall uppfylla.

@RunWith(classOf[JUnitRunner])
class MyApplicationSpec extends FlatSpec with MustMatchers {

  "My application" must "convert a string to hex values" in {
  }

}

Det här är ett komplett test, även om det inte gör något just nu – kroppen på specifikationen är tom. Om jag vill kan jag lämna det tomt och fylla på senare, eller så gör jag det lite tydligare att jag inte är klar med testet. Då skriver vi om det såhär

@RunWith(classOf[JUnitRunner])
class MyApplicationSpec extends FlatSpec with MustMatchers {

  "My application" must "convert a string to hex values" in (pending)

}

Väldigt tydligt och förklarande, eller hur? Ponera att jag skapar en klass som kan konvertera en sträng till hexadecimala värden (wow!). Då kan testkoden se ut som följande

@RunWith(classOf[JUnitRunner])
class MyApplicationSpec extends FlatSpec with MustMatchers {

  "My application" must "convert a string to hex values" in {
    val app = new MyApplication()
    app.convert("The donkey makes a left turn. I observe.") must equal ("54686520646f6e6b6579206d616b65732061206c656674207475726e2e2049206f6273657276652e")
  }

}

Klassen MyApplication är fortfarande skriven i Java, men jag testar den från Scala. Nyckelordet ”must” kommer från en trait i ScalaTest som heter MustMatchers. Det går också att använda ShouldMatchers, enda skillnaden är terminologin – must eller should, vilket du tycker om bäst.

Genom att fylla på med test av det här slaget så får du en ganska tydligt dokumentation vad du faktiskt förväntar dig av dina roller/klasser. Då slipper du en massa kommentarer i koden och/eller testmetoder som döpts ”testShouldConvertStringToHexValue” eller liknande. Enkelt och snyggt!

Vill du använda mockobjekt i din scalakod så kan du antingen köra på någon av de vanliga javabiblioteken (JMock, EasyMock, Mockito), eller så kan du prova Borachio som är skrivet i Scala.

För att testa Logback, lägg till följande maven-beroende:

<dependency>
  <groupId>ch.qos.logback</groupId>
  <artifactId>logback-classic</artifactId>
  <version>1.0.0</version>
</dependency>

Logback-classic beror på logback-core och SLF4J och därför kommer dessa automatiskt inkluderas i projektet. Därefter är det bara att logga på samma sätt som med SLF4J:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
...
Logger logger = LoggerFactory.getLogger(App.class);
logger.info("Hello World!");

Konfiguration påminner om log4j men skiljer sig på vissa punkter. Nedan är ett enkelt exempel på en Logback-konfiguration:

<?xml version="1.0" encoding="UTF-8" ?>
<configuration scan="true" scanPeriod="3 seconds">

    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{32} - %msg%n</pattern>
        </encoder>
    </appender>

    <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>logFile.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>logFile.%d{yyyy-MM-dd_HH-mm}.log.zip</fileNamePattern>
            <maxHistory>5</maxHistory>
        </rollingPolicy>

        <encoder>
            <pattern>%-26(%d{HH:mm:ss,SSS} [%thread]) %-5level %logger{32} - %msg%n</pattern>
        </encoder>
    </appender>

    <root level="DEBUG">
        <appender-ref ref="STDOUT" />
        <appender-ref ref="FILE" />
    </root>

</configuration>

För den som vill komma åt det som denna artikel producerar (finns lite mer godis också i form av enklare ejb och servlet-klasser) så finns den tillgänglig på github:
git clone http://github.com/cygni-stacktrace/j2ee-maven-5minutes

Generera jee-arketyper

Ställ dig i lämplig katalog för att påbörja skapandet av vårt projekt. Första gången vi kör mvn archetype:generate (ska köras sammanlagt 3 ggr) letar vi upp och anger siffran för codehause-arketypen ear-javaee6. För varje gång vi kör kommandot ser infon ungefär likadan ut.

EAR-input:

Define value for property ‘groupId’: : se.cygni.stacktrace.myearproject
Define value for property ‘artifactId’: : my-ear
Define value for property ‘version’:  1.0-SNAPSHOT: :
Define value for property ‘package’:  se.cygni.stacktrace.mywebexample: : ear

Andra gången anger vi siffran för arketypen webapp-javaee6. Input:

Define value for property ‘groupId’: : se.cygni.stacktrace.mywebexample
Define value for property ‘artifactId’: : my-web
Define value for property ‘version’: 1.0-SNAPSHOT: :
Define value for property ‘package’: se.cygni.stacktrace.mywebexample: : war

Tredje gången anger vi siffran för arketypen ejb-javaee6. Input:

Define value for property ‘groupId’: : se.cygni.stacktrace.myejbexample
Define value for property ‘artifactId’: : my-ejb
Define value for property ‘version’:  1.0-SNAPSHOT: :
Define value for property ‘package’:  se.cygni.stacktrace.myejbexample: : ejb

När vi är klara med det här kommer det finnas tre kataloger, my-ear, my-web och my-ejb med varsin pom.xml som har en hyfsat bra grunduppsättning av JEE-beroenden uppsatta från början.

Skapa en parent-pom

För att bland annat kunna bygga hela vår applikation i ett svep kopplar vi ihop dessa my-ear/my-web och my-ejb pom.xml till en och samma parent pom.xml. Skapa manuellt katalogen my-app på samma nivå som de andra katalogerna och en pom.xml fil med bland annat följande (hela my-app/pom.xml kan hittas här):

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>se.cygni.stacktrace</groupId>
  <artifactId>my-app</artifactId>
  <packaging>pom</packaging>
  <version>1.0</version>
  <name>my-app</name>

  <modules>
  	<module>../my-ear</module>
  	<module>../my-web</module>
  	<module>../my-ejb</module>
  </modules>
...

I samband med att vi gör det här så tar vi också bort Version-taggen och sätter parent att vara my-app i pom.xml i my-web, my-ejb och my-ear. Hur alla pom.xml ser ut efter detta kan ses: här.

Nu kan vi nerifrån och upp genom ett kommando bygga web, ejb samt ear. Ställ dig bara i my-app och kör mvn package!

Modifiera ear att innehålla web och ejb-beroenden

Nu kör vi igång eclipse och tar hjälp av de verktyg som finns där för att sätta våra beroende mellan ear och ejb/web-modulerna. En förutsättning är att du har m2e-pluginen installerad i eclipse. Plocka den härifrån http://download.eclipse.org/technology/m2e/releases/ och när det är gjort så importerar du pom.xml i my-app-katalogen in i eclipse (File-> Import -> Maven -> Existing Maven Projects). Det kommer skapa 4 olika projekt i eclipse, my-app, my-ear, my-web och my-ejb.

Öppna upp my-ear/pom.xml och modifiera stycket:

 <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-ear-plugin</artifactId>
        <version>2.6</version>
        <configuration>
            <version>6</version>
            <defaultLibBundleDir>lib</defaultLibBundleDir>
        </configuration>
      </plugin>

till:

			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-ear-plugin</artifactId>
				<version>2.6</version>
				<configuration>
					<version>6</version>
					<defaultLibBundleDir>lib</defaultLibBundleDir>
					<modules>
						<ejbModule>
							<groupId>se.cygni.stacktrace.myejbexample</groupId>
							<artifactId>my-ejb</artifactId>
						</ejbModule>
						<webModule>
							<groupId>se.cygni.stacktrace.mywebexample</groupId>
							<artifactId>my-web</artifactId>
						</webModule>
					</modules>
				</configuration>
			</plugin>

Sen högerklickar du på my-ear-projektet i package explorer och väljer Maven -> Add dependency. I sökrutan anger du ”my-ejb”, då kommer ditt ejb-projekt att dyka upp och du väljer detta och klickar OK. Upprepa proceduren för my-web projektet. Din my-ear/pom.xml bör nu innehålla detta:

	<dependencies>
		<dependency>
			<groupId>se.cygni.stacktrace.mywebexample</groupId>
			<artifactId>my-web</artifactId>
			<version>1.0</version>
			<type>war</type>
		</dependency>
		<dependency>
			<groupId>se.cygni.stacktrace.myejbexample</groupId>
			<artifactId>my-ejb</artifactId>
			<version>1.0</version>
			<type>ejb</type>
		</dependency>
	</dependencies>

Efter det här kan man roa sig med att städa upp ytterligare i sina pom.xml filer genom att t.ex se till att maven-compiler-plugin bara finns i my-app/pom.xml med rätt version etc. Men i princip är din grundstruktur nu klar och du kan ställa dig i my-app och köra mvn package för att få en fin ear-fil som kan deployas på en jee6-kompatibel app-server.

Rapporter, databearbetning eller andra bakgrundsprocesser är förhållandevis vanligt förekommande processer i många system. Dessa processer eller batchjobb kan till exempel vara enkla bash-skript som uppdaterar ett fält i en databas eller applikationer som månatligen skapar komplexa rapporter. Då den här typen av återkommande jobb ibland kräver en del resurser samtidigt som de inte alltid är beroende av att köras tillsammans med en applikation på en applikationsserver lämpar de sig många gånger väl för att köras som fristående program på separata servrar.

Spring Batch är ett ramverk från SpringSource skapat för utveckling av batchjobb. Detta ramverk erbjuder en modell, en samling verktyg samt funktionalitet tänkt att förenkla och standardisera utvecklingen av dessa typer av jobb.

Ett batchjobb i Spring Batch är uppdelat i ett till flera steg. I varje steg läses data från en källa som sedan skrivs till ett mål. Före det att data skrivs kan denna dessutom bearbetas och transformeras i ett separat delsteg. Själva jobben konfigureras i XML men de bönor som används kan viras som vanliga Springbönor via XML eller annotationer. Exemplet nedan, med ett steg, innefattar inläsning från flatfil konfigurerat med den inbyggda läsaren av flatfiler, en enkel processor som konverterar den inlästa textsträngen och en skrivare som loggar den konverterade informationen.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:batch="http://www.springframework.org/schema/batch"
  xsi:schemaLocation="http://www.springframework.org/schema/batch http://www.springframework.org/schema/batch/spring-batch-2.1.xsd
    http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

<batch:job id="readFileJob">
  <batch:step id="step">
    <batch:tasklet
          transaction-manager="transactionManager"
          start-limit="100">
      <batch:chunk
          reader="flatFileItemReader"
          processor="stringLengthProcessor"
          writer="simpleLogWriter"
          commit-interval="5" />
    </batch:tasklet>
  </batch:step>
</batch:job>

<bean id="flatFileItemReader" scope="step"
      class="org.springframework.batch.item.file.FlatFileItemReader">

  <property name="resource" value="${input.file.name}" />
  <property name="lineMapper">
    <bean id="defaultLineMapper" scope="step"
        class="org.springframework.batch.item.file.mapping.PassThroughLineMapper"/>
  </property>
</bean>
</beans>

Spring Batch kommer med inbyggt stöd för att läsa och skriva från och till flertalet olika format och källor, till exempel flatfil, XML och SQL-databaser. Det går självklart att utveckla egna readers och writers då dessa inte täcker de behov som kan tänkas finnas. Flatfilsläsaren är i exemplet konfigurerat att läsa in varje rad i en sträng som därefter skickas till en enkel processor som läser av längden på raden som sedan loggas i writern. Värt att nämna är att Spring Batch 2 stödjer generics.

@Component
public class StringLengthProcessor implements ItemProcessor<String, Integer> {
  @Override
  public Integer process(String s) throws Exception {
    return s == null ? null : s.length();
  }
}

Spring Batch 2 använder chunk-oriented processing. Varje chunk konfigureras med ett commit-interval (5 i exemplet ovan) och det är endast dessa 5 items som jobbet läser och bearbetar innan commit sker mot den konfigurerade writern.

@Component
public class SimpleLogWriter implements ItemWriter<Integer> {
...
  public void write(List<? extends Integer> data) throws Exception {
    for (Integer length : data) {
      logger.info(length);
    }
  }
}

Det krävs en så kallad JobLauncher och ett konfigurerat Job för att köra ett batchjobb. Ett jobb kan till exempel startas från kommandoraden eller från en webbapplikation.

java CommandLineJobRunner readFileJob.xml readFileJob jobDateParam=2011-10-10

CommandLineJobRunner är inbyggd i Spring Batch och kräver två argument. Det första argumentet är jobPath (sökvägen till jobb-konfigurationen) och det andra är jobName (namnet på det jobb som ska köras). Utöver dessa två argument tillkommer jobbparametrar (format namn=värde). Jobbparametrarna sparas i ett jobbrepository och används för att identifiera unika jobbinstanser. Detta medför bland annat att misslyckade jobb kan återupptas och att slutförda jobb inte kommer köras igen. Vanligen är ett jobbrepository en databas men finns det inget behov att hålla reda på vilka jobb som körts och vilka som är slutförda, eller om det finns speciella prestandakrav, går det att konfigurera ett repository som hålls i minnet istället.

Utförlig dokumentation och instruktioner finns här: Spring Batch.

Hur bryter du isär koden så att det går att testa separat då? Jo, här kommer då mockobjekt in i bilden. Med hjälp av dessa syntetiska objekt som representerar dina kodberoenden så kan du isolera den kod som du vill testa, utan att råka ut för NullPointerException. Termen myntades (iallafall för den bredare publiken) av några utvecklare på en extreme-programming-konferens år 2000, där de också presenterade ett första ramverk för detta.

Ponera följande kodexempel (där Courier är ett interface)

class AwesomeApp {
   Courier courier;
   public Content checkPacket() {
      if ( !courier.hasNewPacket() ) {
         throw new NoNewPacketAsFarAsWeCouldSeeException();
      }
      Packet packet = courier.getNewPacket();
      Content content = packet.open();
      return content;
   }
   public void setCourier(Courier courier) {
      this.courier = courier;
   }
}

Om jag skriver följande test, så ramlar jag oundvikligen ned i NullPointerException-gropen eftersom courier är null i AwesomeApp.

class AwesomeAppTest {
   public void testCheckPacket() {
     AwesomeApp app = new AwesomeApp();
     Content content = app.checkPacket();
     // Assert content
   }
}

Vad göra? Lösningen är då alltså att använda ett mockobjekt. Antingen kan jag skriva en egen klass som implementerar interfacet Courier, samt hantera alla testvillkor som objekt av den klassen måste uppfylla, eller så använder jag ett färdigt ramverk. Valet känns lätt. Genom att välja ett färdigt ramverk så slipper jag en del underhåll och får samtidigt ett färdigt utvecklingsmönster att följa – annars kan det lätt bli att varje utvecklare i ett projekt gör på sitt eget sätt.

De vanligaste ramverken som används idag skulle jag säga är EasyMock, JMock samt Mockito. De är alla likvärdiga i funktionalitet och även om konstruktionerna kan skilja sig lite åt så är grunden densamma. Jag har också stött på ett ramverk som heter RMock, men det är gammalt och stöder inte ens Java 5 Generics, så jag tar inte upp det här. Här nedan följer några exempel på hur AwesomeAppTest skulle skrivas med alla tre ramverken, så att läsaren kan jämföra.

JMock

JMock har funnits länge och är en vidareutveckling av det ramverk som presenterades på extreme-programming-konferensen jag nämnde ovan. Version 1 var lite knölig att använda, eftersom metodmatchning gjordes med strängar vilket gav problem vid refaktorisering. Detta är dock löst i version 2 som sedan länge är den som gäller.

class AwesomeAppTest {
   @Test
   public void testCheckPacket() {
      // JMock-specifik klass
      Mockery mockery = new Mockery();
      // Här skapar vi vårt mockobjekt med JMock
      Courier courier = mockery.mock(Courier.class);

      // Förväntat returvärde från testade koden
      Content expectedContent = new Content();
      // Returvärden från mitt mockobjekt
      Packet anyPacket = new Packet(expectedContent); 

      // Definiera våra förväntningar, ett anrop till
      // courier.hasNewPacket() och ett till
      // courier.getNewPacket() samt deras returvärden
      mockery.checking(new Expectations() {{  

         oneOf(courier).hasNewPacket();
         will(returnValue(true));

         oneOf(courier).getNewPacket();
         will(returnValue(anyPacket)); 

      }});

      AwesomeApp app = new AwesomeApp();
      // Här sätter vi vårt mockobjekt som
      // beroende till AwesomeApp
      app.setCourier(courier);
      Content content = app.checkPacket();

      // Kontrollera att resultatet är det förväntade
      assert content == expectedContent;

      // Verifiera att förväntningarna inträffade
      mockery.assertIsSatisfied(); 

   }
}

EasyMock

EasyMock är också ganska gammal i gemet och var tidig med att ha stöd för refaktorisering.

class AwesomeAppTest {
   @Test
   public void testCheckPacket() {
      // Här skapar vi vårt mockobjekt med hjälp av EasyMock
      Courier courier = EasyMock.createMock(Courier.class); 

      // Förväntat returvärde från testade koden
      Content expectedContent = new Content();
      // Returvärden från mitt mockobjekt
      Packet anyPacket = new Packet(expectedContent); 

      // Definiera våra förväntningar, ett anrop till
      // courier.hasNewPacket() och ett till
      // courier.getNewPacket()  samt deras returvärden
      EasyMock.expect(courier.hasNewPacket()).andReturn(true);
      EasyMock.expect(courier.getNewPacket()).andReturn(anyPacket);

      // Sätt EasyMock i replay-läge,
      // där förväntningarna skall uppfyllas
      EasyMock.replay(courier); 

      AwesomeApp app = new AwesomeApp();
      // Här sätter vi vårt mockobjekt som
      // beroende till AwesomeApp
      app.setCourier(courier);
      Content content = app.checkPacket();

      // Kontrollera att resultatet är det förväntade
      assert content == expectedContent;

      // Verifiera att förväntningarna inträffade
      EasyMock.verify(courier);
   }
}

Mockito

Mockito är i praktiken en vidareutveckling av EasyMock, från början en fork som nu har skrivits om helt. Tack vare arvet är dock syntaxen väldigt lik.

class AwesomeAppTest {
   @Test
   public void testCheckPacket() {
      // Här skapar vi vårt mockobjekt med hjälp av Mockito
      Courier courier = Mockito.mock(Courier.class); 

      // Förväntat returvärde från testade koden
      Content expectedContent = new Content();
      // Returvärden från mitt mockobjekt
      Packet anyPacket = new Packet(expectedContent); 

      // Definiera våra förväntningar, ett anrop till
      // courier.hasNewPacket() och ett till
      // courier.getNewPacket() samt deras returvärden
      Mockito.when(courier.hasNewPacket()).thenReturn(true);
      Mockito.when(courier.getNewPacket()).thenReturn(anyPacket);

      AwesomeApp app = new AwesomeApp();
      // Här sätter vi vårt mockobjekt som
      // beroende till AwesomeApp
      app.setCourier(courier);
      Content content = app.checkPacket();

      // Kontrollera att resultatet är det förväntade
      assert content == expectedContent;

      // Verifiera att förväntningarna inträffade
      Mockito.verify(courier);
   }
}

Summering

Som ni ser skiljer det inte mycket mellan ramverken, det som kanske framträder mest är att EasyMock har ett steg extra – där EasyMock sätts i ”replay”-läge – mot både JMock och Mockito. Alla tre har stöd för att verifiera att metodanrop sker i rätt ordning, verifiera argument etc. Det går också att sätta mjukare förväntningar, såsom att en metod skall anropas en eller flera gånger, att man inte bryr sig om anrop och returvärde på ett visst objekt osv.

Vilket ramverk du skall välja är mer upp till personlig smak än funktionalitet. I de flesta fall kanske du sitter i ett projekt som redan använder ett mockramverk och då har du förhoppningsvis fått en lite bättre förståelse för vad ramverket gör.

Som avslutning kan jag rekommendera lite läsning från utvecklarna som myntade begreppet mockobjekt. Du hittar det på www.mockobjects.com – läs gärna deras papper som ligger som länkar i högerkolumnen på den sidan.