Som temporär lösning på problemet har jag lagt följande i filen $HOME/.gsettings som jag sedan läser in i $HOME/.profile.

# Check what bindings are available
# gsettings list-recursively  |grep key|less

gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-left "['<Shift><Control><Alt>Left']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-right "['<Shift><Control><Alt>Right']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-up "['<Shift><Control><Alt>Up']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-down "['<Shift><Control><Alt>Down']"

gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-left "['<Control><Super><Alt>Left']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-right "['<Control><Super><Alt>Right']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-up "['<Control><Super><Alt>Up']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-down "['<Control><Super><Alt>Down']"

gsettings set org.gnome.settings-daemon.plugins.media-keys screensaver '<Super>l'
gsettings set org.gnome.desktop.wm.keybindings begin-move "['<Super>F7']"
gsettings set org.gnome.desktop.wm.keybindings begin-resize "['<Super>F8']"
gsettings set org.gnome.desktop.wm.keybindings show-desktop "['<Super>d']"

gsettings set org.gnome.desktop.wm.keybindings toggle-shaded "['disabled']"

if [ -f "$HOME/.gsettings" ]; then
	. "$HOME/.gsettings"
fi

Använd en bra studieguide

Suns egna certifieringsböcker är guld värda. Varje ämne betas noggrant och metodiskt av i lagom stora kapitel. Där beskrivs precis vad du behöver veta för att klara provet med väl förklarande kodexempel. Varje kapitel har även ett gäng examinationsfrågor där du kan kolla om du snappat upp vad kapitlet handlat om och en kortare sammanfattning tillsammans med en punktlista av de viktigaste sakerna. Punktlistans påståenden passar utmärkt att göra flashcards av för att ha när man repeterar! Håll i åtanke att det kanske inte räcker att läsa boken bara en gång…

• SCJP Sun Certified Programmer For Java 6 Exam

Gå tillbaka till grunderna

Få inte panik om begreppen och språken i studieguiden är lite över huvudet. De flesta som studerar till certifieringen har några års erfarenhet av Java och programmering och har man inte koll på begreppen är det bättre att gå tillbaka till något mer grundläggande studiematerial  och reda ut dessa ord innan man går vidare med certifieringsguiden. Inför provet är det viktigt att komma ihåg att man inte bara ska kunna koda utan även prata om kod. Många begrepp handlar just om att beskriva kod eller prata runt hur man ska koda för att uppnå vissa resultat som kanske har med prestanda, säkerhet eller arkitektur att göra. Eller bara kunna definitionen på t ex vad ett interface är. Plugga begreppen, inte bara koden.

Gör examinationsfrågor

Ibland tror man att man kan något tills man ställs inför en fråga. Examinationsfrågorna i boken är perfekta för att kolla om man verkligen har förstått det man tror att man har förstått. När det gäller kod ska man inte bara ha koll på den rekommenderade standarden, men också alla möjliga godkända sätt att skriva, även de som inte är särskilt snygga. Du ska kunna skillnaden på om koden inte kompilerar eller kastar ett exception, eller bara är fult skriven och inte följer standardsättet men fungerar!  Testfrågor finns även att få tag i på diverse olika webbsidor, i mobilappar, eller i Suns egna böcker med “inför-testet-test”.

• OCP Java SE 6 Programmer Practice Exams
• SCJP mock test online

Koda

Ett bra sätt att lära sig det som man kanske inte stött på så mycket förut är att koda det. Speciellt de områden som handlar om att pussla ihop flera klasser för att få ihop en funktionalitet; till exempel att läsa/skriva från fil eller interfacen Comparable och Comparator. Så ge dig själv lite kodtid med det som känns lite extra svårt. Och testa även att koda på fri hand, dvs utan en IDE eller en javadoc i närheten. Det är ett bra sätt att använda hjärnan och se hur mycket du kommer ihåg av klassernas metoder. Men kolla givetivs upp om du fastnar helt, men då kan du grejerna sen till nästa gång!

Fokusera på det som är svårt

När du läst boken, pluggat grundläggande begrepp, nött frågor, och kodat dig trött. Gör ett test med 60 frågor, skriv ner vad vilka områden du hade fel på och börja om från början igen och plugga på det du uppenbarligen inte har koll på. Så, starta om, men fokusera på det som du tycker är svårt. Läs igenom texterna igen, koda ett exempel, försöka utforska klassen eller ett api genom att fundera och expermintera, vad händer om jag skriver så här, osv. Iterera samma sätt om och om igen, tills allt sitter som en smäck.

Hela listan finns här.

Grundkrav

• VirtualBox – Installation av VirtualBox sker via nedladdning från https://www.virtualbox.org/wiki/Downloads
• Vagrant – Installation av Vagrant sker via Vagrants egen installer eller via följande gem:

  $ gem install vagrant
  

Sätt igång

Då är vi redo att börja. För att skapa en ny virtuell box med Ubuntu 12.04 LTS kör du bara följande kommandon:

$ vagrant box add precise64 http://files.vagrantup.com/precise64.box
$ mkdir -p testenv
$ cd testenv
$ vagrant init precise64
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

Kommandot på rad 1 laddar ned en färdig box med Ubuntu 12.04 LTS. Denna box namnges till precise64 och kan sedan återanvändas för flera virtuella maskiner. Nedladdning sker endast en gång. Rad 2 och 3 skapar en katalog där din virtuella maskin sparas. Kommandot på rad 4 skapar en så kallad Vagrantfile som beskriver hur just din box ska konfigureras (bland annat port forwarding). Vagrant själva skriver att:

A Vagrantfile is to Vagrant as a Makefile is to Make

Innehållet i vår nyskapade Vagrantfile ser ut ungefär så här:

Vagrant::Config.run do |config|
  # Setup the box
  config.vm.box = "precise64"
end

Den katalogen som innehåller Vagrantfile mappas (per default) upp som en shared folder så din maskin och den virtuella boxen kan dela filer där på ett smidigt sätt.

För att sedan starta vår virtuella server används följande kommando:

$ vagrant up

Och för att koppla upp dig via SSH mot servern körs detta kommando:

$ vagrant ssh

När du kopplat upp dig via SSH kan du accessa dina delade filer i foldern /vagrant

Om du gör förändringar av din virtuella box som du sedan vill återanvända kan du skapa egna paket (boxar) som du senare kan utgå från. Detta sker enkelt via kommandot:

$ vagrant package

Då skapas en box – package.box – som kan läggas till bland dina befintliga boxar med hjälp av

$ vagrant box add my_box /path/to/package.box

När du känner att du är färdig med din virtuella box kan du använda följande kommando för att stänga ned maskinen (och därmed spara CPU/RAM):

$ vagrant halt

Alternativt, om du bara vill göra en suspend (det går snabbare att starta maskinen senare isf):

$ vagrant suspend

För att starta maskinen efter halt eller suspend är det bara att köra:

$ vagrant up

Om du vill ta bort din virtuella box från disken helt och hållet kör du bara kommandot:

$ vagrant destroy

Vagrant erbjuder också stöd för mer avancerade features såsom provisioning mha Chef eller Puppet. Allt detta finns att läsa på Vagrants hemsida.

Så, superenkel hantering av virtuella boxar med hjälp av Vagrant – rekommenderas varmt!

Lathund:

Prisbelönta hitta.se hjälper dagligen hundratusentals svenskar att hitta företag, personer och platser. På hitta.se finns adresser och telefonnummer till alla svenska företag och privatpersoner. Dessutom finns branschsök, kartor, vägbeskrivningar, gatubilder, satellitbilder och mycket annat som hjälper till att hitta rätt.

Avtalet befäster ytterligare Cygnis ställning som en av de ledande kvalitetsleverantörerna av systemutvecklingstjänster för högt trafikerade webbplatser.

Även om man utvecklar enligt TDD (Test Driven Development) så kan det vara bra att få ett kvitto på att ens egen bild av testerna stämmer överens med verkligheten. För den som inte utvecklar testdrivet är EMMA en riktig ”eye-opener” för att, allt som oftast, inse att det behövs fler tester.

Jag fortsätter med ett exempel av Hello World-kaliber. Ladda gärna hem pluginen själv och prova samtidigt, projektets hemsida är www.eclemma.org där du kan välja manuell nerladdning eller använda länken till projektets update-site, samt att det finns tillgängligt i Eclipse Marketplace.

Då kör vi. Testet ser ut såhär:

public class EmmaTest {

 @Test
 public void testGreeter() {
    Greeter greeter = new Greeter();
    Assert.assertEquals("Hello Cygni!", greeter.greet("Cygni"));
 }
}

Och klassen vi ska testa:

public class Greeter {

 public String greet(String name) {
    if(name != null) {
       return "Hello " + name + "!";
    } else {
       return "Who are you?";
    }
 }

 public String greetSimple() {
    return "Hello you!";
 }
}

Att testet inte täcker hela Greeter-klassen har du nog redan insett. Vi låter dock EclEmma sköta analysen.

När EclEmma är installerat dyker ytterligare ett alternativ för att exekvera upp. Sedan tidigare har vi Run as och Debug as, men nu kommer även Coverage as att finnas tillgängligt. Om du kör Java-perspektivet skall också en ikon för detta ha tillkommit (kör du andra perspektiv kan du behöva lägga till ikonen via ”Customize perspective”). Vi kör testet via Coverage as:

Testet körs och vi får upp Coverage-vyn, samt att kodraderna i de klasser där det körts kod kommer att ha fått lite färg. Vi börjar med Coverage-vyn:

Som synes kan vi gå ner på olika nivåer för att tydligare se var det täcker bättre eller sämre. Efter att ha expanderat trädet fullt ut ner på metodnivå ser vi att greetSimple() har 0% täckning och att greet() behöver testas mer för att nå 100%. Metoden greetSimple() tog jag bara med här för att visa på hur användbart det är att kunna se test coverage på metodnivå och på så sätt tydligare identifiera svagheter, men jag låter den vara otestad för det här exemplet.

Om vi öppnar klassen Greeter, så ser ni tydligt vad som är testat och inte:

I greetSimple() är det inte så mycket att tala om, den är röd (no coverage) eftersom vi inte har något test som kör metoden. I greet() är raden med ”Who are you?” röd eftersom vi inte har gjort något anrop där if-satsen utvärderas till false.

Den gröna raden är grön (full coverage) därför att det är den rad som exekverades när metoden returnerade ”Hello Cygni!”, det väntade resultatet av vårt test.

Den gula raden betyder att raden är delvis täckt (partial coverage), en mycket användbar indikator. I det här fallet vet vi att det finns två scenarion för if-satsen. Antingen har argumentet name värdet null, eller så är name skilt från null. I vårt test skickade vi in ”Cygni”, name var alltså skilt från null. EclEmma talar också om för oss hur många fall vi har missat om vi håller muspekaren över diamantikonen bredvid:

Vi skriver ytterligare ett test för att nå 100% test coverage i metoden greet():

@Test
 public void testGreeterNullArg() {
    Greeter greeter = new Greeter();
    Assert.assertEquals("Who are you?", greeter.greet(null));
 }

Resultatet ser nu mycket trevligare ut:

En inställning som är bra att känna till är vilken typ av counter man kör. Hur stor test coverage dina tester har kan variera stort beroende på hur man räknar. I vårt exempel kunde vi se att vi i if-satsen hade två stycken branches. I första testet kördes bara ett anrop där uttrycket i if-satsen var sant (name var skilt från null), vilket innebar att vi täckte en branch av två – branchen där name var null kördes inte. Alltså hade vi i det testet 50% branch coverage på den raden.

Men, om vi istället räknar line coverage, så är siffran 100% eftersom line coverage inte tar hänsyn till vilken typ av kodrad som exekveras, bara att den exekveras. Klicka på den vita nedåtriktade pilen i coverage-vyn för att ändra typ av counter:

Du kan läsa mer om de olika typerna av counters som finns på EclEmma‘s hemsida eller exempelvis Wikipedia.

Två tips innan vi är färdiga:

1. EMMA och andra liknande verktyg (Cobertura till exempel) finns som plugins till exempelvis Maven och Jenkins, som då genererar en rapport över hur testerna gick i ett bygge. Att ha statistik och rapporter över testresultat och trender i projektet ger en trevlig överblick.
2. Om du kör ett mörkt tema för Eclipse, vilket inte är särskilt ovanligt, rekommenderar jag att ändra highlight-färgerna för EclEmma, annars är risken stor att du inte ser texten på raderna. Gå till Window -> Preferences -> General -> Editors -> Text Editors -> Annotations och välj mörkare färger för alternativen Full coverage, Partial coverage och No coverage.

Begrepp

Dropwizard har idenitifierat följande aktörer och entiteter i sin stack:

Configuration

Konfigurationen är till för att hålla miljöspecifika aspekter av tjänsten. Det kan t.ex vara databaskonfiguration eller nödvändiga sökvägar och url:ar. Konfigurationen skrivs i formatet YAML. Genom JSON-annotationer i din klass läser DropWizard automatiskt upp konfigurationen och populerar din konfigurationsklass.

Representation

Detta är de objekt som ska skickas mellan klient och server och är i sin enklaste form vanliga POJOs. Jackson används för serialisering och deserialisering. DropWizard rekommenderar att dessa objekt är immutable.

Resource

Det är resurserna som exponerar REST API:et. Varje resurs och metod har en URI och klassen annoteras med javax.ws.rs.*-typerna för att definiera sökvägar, innehållstyper och metod. DropWizard använder Jersey-implementationen.

Health check

Hälsokontroller är små kodsnuttar som testar att tjänsten är uppe och att allt är som det ska. Status för hälsokontrollerna kan inspekteras via en speciell admin-url. DropWizard skapar automatiskt några hälsokontroller, bl.a en som kontrollerar att databasanslutningen är korrekt (om man har en i sitt projekt).

Service

Servicen ansvarar för att dra igång tjänsten med en konfiguration och med resurserna initialiserade med eventuella beroenden. Detta sker genom en vanlig main-metod(public static void main(String[] args) { ... } ).

I vårt exempelprojekt ser serviceklassen ut så här:

public class MainService extends Service<MainConfiguration> {
    public static void main(String[] args) throws Exception {
        new MainService().run(args);
    }

    @Override
    public void initialize(Bootstrap<MainConfiguration> mainConfigurationBootstrap) {
        mainConfigurationBootstrap.addBundle(new AssetsBundle("/assets/", "/"));
    }

    @Override
    public void run(MainConfiguration config, Environment environment) throws Exception {

        DBI dbi = initDatabaseConnection(config, environment);

        final EventsRepository eventsRepository = dbi.onDemand(EventsRepository.class);
        final ExpensesRepository expensesRepository = dbi.onDemand(ExpensesRepository.class);

        environment.addResource(new EventsResource(eventsRepository));
        environment.addResource(new ExpensesResource(expensesRepository));
    }

    private DBI initDatabaseConnection(MainConfiguration config, Environment environment) throws ClassNotFoundException {

        final DBIFactory factory = new DBIFactory();
        final DBI jdbi = factory.build(environment, config.getDatabaseConfiguration(), "db");

        createTables(jdbi);

        return jdbi;
    }

    private void createTables(DBI dbi) {

        Handle handle = dbi.open();

        handle.execute(EventsRepository.CREATE_TABLE_STATEMENT);

        handle.execute(ExpensesRepository.CREATE_TABLE_STATEMENT);

        handle.close();
    }
}

För dig som är van vid Spring eller något annat DI-ramverk kan det kännas lite konstigt att själv behöva instansiera t.ex resursklasserna (och skjuta in Repository-implementationerna). Eftersom tanken med en DropWizard tjänst är att ansvara för en relativt liten delmängd av ett system så tycker jag inte att detta är särskilt besvärande.

Resurser, dvs REST-tjänsterna, aktiveras genom att lägga till dem till instansen av Environment. Se rad 19-20 ovan.

Komma igång

Checka ut exempelprojektet och bygg:

git clone git://github.com/cygni-stacktrace/dropwizard-sample.git
cd dropwizard-sample
mvn package

Starta tjänsten med kommandot server och filnamnet för konfigurationen:

java -jar target/expenses-1.0-SNAPSHOT.jar server development.yml

Rest-API:et ligger under kontextet /api, en GET-operation för att lista events finns t.ex här: http://localhost:8080/api/event

Admingränssnittet med länk till Health check finns här: http://localhost:8081

Testning

Testning av resurser är en enkel historia med DropWizard. Genom att låta din testklass uttöka ResourceTest kan du lägga till resursen under test så här:

    @Override
    protected void setUpResources() throws Exception {
        eventsRepository = mock(EventsRepository.class);
        addResource(new EventsResource(eventsRepository));
    }

En testmetod:

    @Test
    public void shouldShowOneEvent() throws IOException {
        //given
        Event event = new Event(1, "An event", null);

        given(eventsRepository.findById(event.getId())).willReturn(event);

        //when
        Event result = client().resource("/event/1").get(Event.class);

        //then
        assertThat("event should be returned", result, is(event));
    }

Dropwizard drar igång Jersey och invokerar anropen i testet via en HTTP-klient så hela request/response kedjan går över JSON och HTTP. Detta är bra för då testas även att Jackson kan serialisera och deserialisera dina POJO:s.

Databasstöd

Dropwizard har moduler med stöd för Hibernate och JDBI. I exempelprojektet används JDBI.

Slutsats

Det är väldigt lätt att komma igång med Dropwizard och jag tycker att de valt en vettig stack med hjälpbibliotek. Den föreslagna projektstrukturen och användandet av Maven gör att det fungerar bra i alla stora IDE:er. Att inkludera Health checks direkt från början känns väldigt bra och det är befriande att ha en app som kan köras helt stand-alone (d.v.s den behöver inte deployas i en webcontainer). Jag tycker också att de tänkt till bra kring testningen.

Om man planerar att börja använda Dropwizard i ett större sammanhang behövs dock en strategi för hur tjänster ska kunna versionshanteras samt upptäckas.

Vidare läsning

http://dropwizard.codahale.com

try {
   ...
} catch(SomeCheckedException e) {
   e.printStackTrace();
}

är ett anti-pattern och definitivt ej bör rekommenderas som ett generellt felhanteringsmönster.

Vad är det då för fel på denna konstruktion? Jo, problemet är att den bryter mot en bra grundprincip inom felhantering, ”fail fast”.

Principen ”fail fast” bygger på att man avbryter programmet så fort ett fel uppstår. Huvudorsaken till att avbryta tidigt är att undvika följdfel. Samtidigt så undviks maskeringar av fel, vilket gör det lättare att diagnostisera och korrigera brister. Följs denna teknik och kombineras med vältäckande tester kan man eliminera många buggar och uppnå en hög genomgående kvalité i sin produkt.

När denna princip är på plats kan man sedan välja göra programmet mer flexibelt genom att selektivt lägga till felhanteringsstrategier.

Detta görs ofta genom att lägga till alternativa strategier för specifika felfall. Detta benämns ofta som ”graceful degradation”. Som ett exempel kan man tänka sig en e-handel som köar upp ordrar då kontakten med banken faller bort. Har man en sådan ”plan b” så har man täckt upp för det specifika felfallet att kontakten med banken faller bort. Ett annat exempel är att falla tillbaka till en enklare webbsida då en plug-in saknas eller en äldre browser används.

För oplanerade fel, sådana där man ofta inte har någon uttänkt strategi, är det bästa man kan göra att återställa systemet till ett känt säkert läge. Ett allmängiltigt sätt att skicka ett program till ett känt läge är att avbryta det. Är ditt system inte livsuppehållande eller på annat sätt kritiskt är detta läge även säkert. Så en bra grundstrategi är att avbryta programmet när ett okänt fel uppstår.

Tillbaka då till strategin att anropa printStackTrace(). Denna felhanterare gör två saker:

1. Skriver ut en felrapport
2. Fortsätter exekveringen av programmet

Det är i huvudsak punkt två som bryter mot ”fail fast”. Om man har en ”graceful degradation” eller ”fail safe”-strategi på plats så bör man när man fångat felet anropa ”plan b”, inte bara fortsätta. Är felet istället oplanerat så bör man så snart som möjligt försätta programmet i ett säkert läge och skriva ut en felrapport.

I printStackTrace-fallet försätts inte programmet i ett säkert läge. Programmet tillåts fortsätta att exekvera och kommer förmodligen trigga följdfel. I avseendet följdfel är därmed denna form av felhantering inte bättre än det välkända anti-patternet att svälja felet helt:

try {
   ...
} catch(SomeCheckedException e) {
  //dålig taktik
  //no-op
}

. Inte heller taktiken att skriva ut felrapporten på en logg undslipper detta argument:

try {
   ...
} catch(SomeCheckedException e) {
   //dålig taktik
  logger.error(e);
}

. En tredje teknik som förekommer är log and throw:

try {
   ...
} catch(SomeCheckedException e) {
   //dålig taktik
  logger.error(e);
  throw new RuntimeException(e);
}

. Att kasta vidare räcker gott och väl, annars riskerar man flera utskrifter för samma fel.

Man vill alltså försätta programmet i ett säkert läge. Dessutom vill man ha en felutskrift utan duplikat. Vän av ordning frågar sig såklart hur man åstadkommer detta på ett enkelt sätt. Svaret är enkelt: kasta exceptionet vidare:

try {
   ...
} catch(SomeCheckedException e) {
   //bra taktik
  throw new RuntimeException(e);
}

.
Vad åstadkommer en sådan konstruktion? Jo, felet kommer att propageras uppåt i stacken tills det når trådens topp, där ett stacktrace skrivs ut innan tråden avslutas. Detta beteende är inbyggt i Java. Har du en enkel applikation med endast en non-deamon-tråd så kommer programmet även att avslutas i samband med att ditt fel skrivs ut. Fallet multitrådade program är mer invecklat och tas inte upp i detta inlägg.

För att på ett enkelt sätt kunna följa dessa principer rekommenderar jag att du ändrar mallen för ”surround with try-catch” i ditt IDE så att den kastar checked exceptions vidare, istället för att anropa printStackTrace().

I Eclipse kan du göra detta i inställningen Java > Code Style > Code Templates och ändra från default

// ${todo} Auto-generated catch block
${exception_var}.printStackTrace();

till

throw new RuntimeException(${exception_var});

På detta sätt får du den bra taktiken per default när du gör ”quick fix”!

Del två visar på användningen av parametriserade tester och hur man på ett bra sätt kan använda extern testdata (testfixtures).

Denna sista del visar hur man kan koppla ihop sina testsviter med open source-verktyget TestLink för att få fram trevliga rapporter.

Koppling mot TestLink

TestLink är ett open source-verktyg där du kan samla ett projekts krav och testfall. Testfallen kan sedan grupperas i olika testplaner inför exempelvis en ny release.

TestLink har ett  XML/RPC-gränssnitt som kan användas för att hämta information om testprojekt, testplaner, testresult mm, men som även kan användas för att uppdatera TestLink med resultatet från en testkörning. Implementationer av detta gränssnitt finns i flera språk såsom Ruby, Python och Java. En javaimplementation – TestLink Java API – finns här.

Utvecklarna av TestLink Java API har som ambition är att vara synkade med den senaste version av TestLinks XML/RPC-gränssnitt. Senaste version när detta skrivs är 1.9.4-0. För att använda TestLink Java API måste du lägga till följande beroende i din Maven-POM.

<dependency>
	<groupId>br.eti.kinoshita</groupId>
	<artifactId>testlink-java-api</artifactId>
	<version>1.9.4-0</version>
</dependency>

Följande hjälpklass implementerar stöd för att hämta projekt, testplan mm från TestLink samt även uppdatera ett exekverat testfall med resultatet.

package se.cygni.testlink;

import java.net.URL;
import java.util.HashMap;
import java.util.Map;

import br.eti.kinoshita.testlinkjavaapi.TestLinkAPI;
import br.eti.kinoshita.testlinkjavaapi.constants.ExecutionStatus;
import br.eti.kinoshita.testlinkjavaapi.model.Build;
import br.eti.kinoshita.testlinkjavaapi.model.Platform;
import br.eti.kinoshita.testlinkjavaapi.model.TestCase;
import br.eti.kinoshita.testlinkjavaapi.model.TestPlan;
import br.eti.kinoshita.testlinkjavaapi.model.TestProject;

public class TestLinkAPIHelper {

 private static TestLinkAPIHelper INSTANCE = new TestLinkAPIHelper();
 private TestLinkAPI m_api;

 private TestLinkAPIHelper() {
   try {
     URL url = new URL("/lib/api/xmlrpc.php");
     m_api = new TestLinkAPI(url, "");
   } catch (Exception e) {
     e.printStackTrace(System.out);
     throw new RuntimeException("Unable to create TestLinkApi");
   }
 }

 public static TestLinkAPIHelper getInstance() {
   return INSTANCE;
 }

 public TestProject getProject(String projectName) {
   return m_api.getTestProjectByName(projectName);
 }

 public TestPlan getTestPlan(TestProject project, String testPlanName) {
   return m_api.getTestPlanByName(testPlanName, project.getName());
 }

 public Platform getPlatform(TestPlan testPlan, String platformName) {
   Platform[] platforms = m_api.getTestPlanPlatforms(testPlan.getId());
   for (Platform platform: platforms) {
     if (platformName.equals(platform.getName())) {
       return platform;
     }
   }
   return null;
 }

 public Build getBuild(TestPlan plan, String buildName) {
   Build[] builds = m_api.getBuildsForTestPlan(plan.getId());
   for (Build build: builds) {
     if (buildName.equals(build.getName())) {
       return build;
     }
   }
   return null;
 }

 public TestCase[] getTestCases(TestPlan plan, Build build) {
   return m_api.getTestCasesForTestPlan(plan.getId(), null, build.getId(), null, null, null, null, null, null, false, null);
 }

 public void reportResult(TestPlan plan,Build build, Platform platform,TestCase testCase, ExecutionStatus status, String notes) {
   System.out.println(String.format("[TestLink] Reporting status %s for test case SP-%s",status.name(),testCase.getFullExternalId()));
   m_api.reportTCResult(testCase.getId(), null, plan.getId(), status, build.getId(), null, notes, false, null, platform.getId(), null, null, false);
 }

 public TestCase addTestCaseToTestPlan(TestProject project, TestPlan plan, String fullExternalId,Platform platform) {
   TestCase testCase = getTestCase(fullExternalId);
   m_api.addTestCaseToTestPlan(project.getId(), plan.getId(), testCase.getId(), testCase.getVersion(), platform.getId(),null , null);
   return testCase;
 }

 public TestCase getTestCase(String fullExternalId) {
   return m_api.getTestCaseByExternalId(fullExternalId, null);
 }

}

Andra argumentet i konstruktionen av TestLinkAPI på rad 23 skall vara din developer-key, ett hexadecimalt tal som kan genereras när du skapar den testanvändare som skall ”köra” de automatiska integrationstesterna. Hur du gör för att skapa denna nyckel finns beskrivet här.

Nu är vi klara att för att uppdatera TestLink med resultatet från våra testkörningar, men hur ser vi till att vår hjälpklass anropas?

Ett antal saker krävs:

1. Vi måste bli notifierade när ett testfall har körts klarts med uppgift om i fall testen gick bra eller inte
2. Vi måste när detta sker kunna anropa vår hjälpklass med korrekt TestLink-projekt, testplan, testfallsid mm

En testrunner exekverar ett enskilt testfall genom ett anrop till metoden runChild(final FrameworkMethod method, RunNotifier notifier) där instansen av RunNotifier blir notifierad varje gång ett testfall har körts klart. Notifiern ansvarar för att uppdatera alla som har registrerat sig som lyssnare på testfallskörningar. Detta kan vi utnyttja för att lösa punkt 1 ovan genom att överrida runChild i en egen testrunner, och där registrera en egen lyssnare . Denna lyssnare skall när testfallet har kört klart rapportera resultatet.

Låt oss först definiera ett interface för de klasser som skall ansvara för att rapportera testresult till exempelvis ett externt system såsom TestLink:

package se.cygni.testlink;

import org.junit.runner.Description;
import org.junit.runner.notification.Failure;

public interface TestReporter {

 void reportTestFailure(Failure failure);
 void reportTestSuccess(Description description);
 boolean testShouldBeRun(Description description);

}

Nu till vår testrunner som överrider runChild:

package se.cygni.testlink;

import org.junit.Ignore;
import org.junit.runner.Description;
import org.junit.runner.notification.Failure;
import org.junit.runner.notification.RunListener;
import org.junit.runner.notification.RunNotifier;
import org.junit.runners.model.FrameworkMethod;

import se.cygni.fibonaccitest.ConcurrentJUnitRunner;

/**
 *
 * Abstract test runner with support for reporting the test results
 * to an external target, i.e. a test management tool such as TestLink.
 *
 */
public abstract class AbstractReportingTestRunner extends ConcurrentJUnitRunner {

 public AbstractReportingTestRunner(Class<?> klass) throws Throwable {
   super(klass);
 }

 @Override
 protected void runChild(final FrameworkMethod method, RunNotifier notifier) {
   Description description = describeChild(method);
   if (method.getAnnotation(Ignore.class) != null) {
     notifier.fireTestIgnored(description);
   } else {
     if (testShouldBeRun(description)) {
       RunListener listener = new ResultListener(description);
       notifier.addListener(listener);
       try {
         runLeaf(methodBlock(method), description, notifier);
       } catch (Exception e) {
         handleTestFailure(new Failure(description, e));
       } finally {
         notifier.removeListener(listener);
       }
     }
   }
 }

 protected void handleTestFailure(Failure failure) {
   getTestReporter().reportTestFailure(failure);
 }

 protected void handleTestSuccess(Description description) {
   getTestReporter().reportTestSuccess(description);
 }

 protected boolean shouldTestBeRun(Description description) {
   return getTestReporter().shouldTestBeRun(description);
 }

 protected abstract TestReporter getTestReporter();

 /**
   *
   * RunListener, listening for the execution result of
   * a test case.
   *
   */
 private class ResultListener extends RunListener {

 private boolean m_failure = false;
 private Description m_description;

 public ResultListener(Description description) {
 m_description = description;
 }

 @Override
 public void testFailure(Failure failure) throws Exception {
 if (isForMe(failure.getDescription())) {
 handleTestFailure(failure);
 m_failure = true;
 }
 }

 @Override
 public void testFinished(Description description) throws Exception {
 if (isForMe(description)) {
 if (!m_failure) {
 handleTestSuccess(m_description);
 }
 }
 }

 @Override
 public void testAssumptionFailure(Failure failure) {
 if (isForMe(failure.getDescription())) {
 handleTestFailure(failure);
 m_failure = true;
 }
 }

 private boolean isForMe(Description description) {
 return m_description.getDisplayName().equals(description.getDisplayName());
 }
 }
}

Ovanstående är en abstrakt klass där konkreta subklasser är tänkt att implementera getTestReporter och svara med en egen test reporter.
Ett (trivialt) exempel som använder sig av en implementation av TestReporter som loggar till konsolen:

public LogToConsoleTestRunner extends AbstractReportingTestRunner {
  public LogToConsoleTestRunner(Class<?> klass) {
    super(klass);
  }
  @Override
  protected TestReporter getTestReporter() {
    return new TestReporter() {

     @Override
     public void reportTestFailure(Failure failure) {
       Description description = failure.getDescription();
       System.out.println(String.format("%s FAILED. Reason %s", description.getDisplayName(),failure.getMessage()));
    }

    @Override
      public void reportTestSuccess(Description description) {
      System.out.println(String.format("%s PASSED.", description.getDisplayName()));
    }

    @Override
    public boolean testShouldBeRun(Description description) {
      return true;
    }

  };
 }
}

Om vi använder LogToConsoleTestRunner för att exekvera följande testklass som testar en fiktiv Calculator (observera felet i test_subtraction).

 package se.cygni.testreport;

 import static org.junit.Assert.*;

 import org.junit.Test;
 import org.junit.runner.RunWith;

 @RunWith(LogToConsoleTestRunner.class)
 public class CalculatorTest {

   @Test
   public void test_addition() {
     assertEquals(5,Calculator.add(2,3));
   }

   @Test
   public void test_subtraction() {
    assertEquals(5,Calculator.subtract(8,2));
   }

}

så kommer följande att loggas i konsolen

test_subtraction(se.cygni.testreport.CalculatorTest) FAILED. Reason expected:<5> but was:<6>
test_addition(se.cygni.testreport.CalculatorTest) PASSED.

För att slutligen knyta ihop exekveringen av vårt testfall med en uppdatering av TestLink behövs ytterligare några byggstenar.

Först en implementation av TestReporter som använder TestLinkAPIHelper för att uppdatera TestLink:

package se.cygni.testlink;

import java.util.HashMap;
import java.util.Map;

import org.junit.runner.Description;
import org.junit.runner.notification.Failure;

import se.cygni.testreport.TestReporter;
import br.eti.kinoshita.testlinkjavaapi.constants.ExecutionStatus;
import br.eti.kinoshita.testlinkjavaapi.model.Build;
import br.eti.kinoshita.testlinkjavaapi.model.Platform;
import br.eti.kinoshita.testlinkjavaapi.model.TestCase;
import br.eti.kinoshita.testlinkjavaapi.model.TestPlan;
import br.eti.kinoshita.testlinkjavaapi.model.TestProject;

/**
 *
 * Implementation of {@link TestReporter}, responsible for reporting the
 * test result to the test plan in TestLink as the test cases are executed.
 *
 * There is only one instance of this class per test execution and
 * it's configured with project, test plan, platform and build, read
 * from an external configuration.
 *
 *
 */
public class TestLinkReporter implements TestReporter {

 // In TestLink it is possible to define a prefix that
 // will be added to all test case ids.
 // getFullExternalId will return id w/o this prefix though.
 private static String TEST_ID_PREFIX = "";

 private TestLinkAPIHelper m_helper;
 private TestProject m_project;
 private TestPlan m_plan;
 private Platform m_platform;
 private Build m_build;
 private Map m_testCases = new HashMap();

 public TestLinkReporter(String project, String testPlan, String platform, String build) {
 System.out.println(String.format("Running tests updating project %s, test plan %s, platform%s and build %s",project,testPlan,platform,build));
 m_helper = TestLinkAPIHelper.getInstance();
 init(project, testPlan, platform, build);
 }

 private void init(String project, String testPlan, String platform, String build) {
 m_project = m_helper.getProject(project);
 m_plan = m_helper.getTestPlan(m_project, testPlan);
 m_platform = m_helper.getPlatform(m_plan, platform);
 m_build = m_helper.getBuild(m_plan, build);
 TestCase[] testCases = m_helper.getTestCases(m_plan, m_build);
 for (TestCase testCase : testCases) {
 m_testCases.put(TEST_ID_PREFIX + testCase.getFullExternalId(), testCase);
 }
 }

 public void reportTestFailure(Failure failure) {
 TestId[] testIds = getTestIds(failure.getDescription());
 for (TestId testId : testIds) {
 reportTestResult(testId,new Failed(testId,failure));
 }
 }

 public void reportTestSuccess(Description description) {
 TestId[] testIds = getTestIds(description);
 for (TestId testId : testIds) {
 reportTestResult(testId,new Passed(testId,description));
 }
 }

 @Override
 public boolean testShouldBeRun(Description description) {
 return getTestLinkAnnotation(description) != null;
 }

 private TestLink getTestLinkAnnotation(Description description) {
 return description.getAnnotation(TestLink.class);
 }

 private TestId[] getTestIds(Description description) {
 TestLink testLink = getTestLinkAnnotation(description);
 if (testLink != null) {
 String[] ids = testLink.id().split(",");
 TestId[] testIds = new TestId[ids.length];
 for (int i = 0; i < ids.length ; i++) {
 testIds[i] = new TestId(ids[i].trim());
 }
 return testIds;
 } else {
 return new TestId[0];
 }
 }

 private void reportTestResult(TestId testId,TestResult testResult) {
 if (testId == null) {
 System.out.println(String.format("Invalid test id format'%s', unable to update TestLink.", testId));
 return;
 }
 TestCase testCase = getOrAddTestCase(testId);
 if (testCase != null) {
 m_helper.reportResult(m_plan, m_build, m_platform, testCase, testResult.getExecutionStatus(), testResult.getNotes());
 } else {
 System.out.println(String.format("Test case '%s' is not in test plan and not able to add it!", testId));
 }
 }
 private TestCase getOrAddTestCase(TestId testId) {
 TestCase testCase = getTestCase(testId.id);
 if (testCase == null) {
 System.out.println(String.format("Test case '%s' is not in test plan, will be added.", testId.id));
 testCase = m_helper.addTestCaseToTestPlan(m_project, m_plan, testId.id, m_platform);
 testCase.setFullExternalId(testId.id);
 m_testCases.put(testId.id, testCase);
 }
 return testCase;
 }

 private TestCase getTestCase(String testId) {
 return m_testCases.get(testId);
 }

 /**
   *
   * Utility class holding the internal test id,
   * i.e. the actual test case id, such as 'SP-472'
   *
   *
   */
 private static class TestId {
 public String id;

 public TestId(String id) {
 this.id = id;
 }

 public String toString() {
 return id;
 }
 }

 /**
   *
   * Internal classes representing the different test results
   * for a test case execution.
   *
 */
 private static abstract class TestResult {
 public TestId testId;
 public String testDescription;

 protected TestResult(TestId testId, Description description) {
 this.testId = testId;
 testDescription = getTestDescription(description);
 }

 public abstract ExecutionStatus getExecutionStatus();
 public abstract String getNotes();
 public abstract boolean passed();
 public abstract boolean failed();
 public abstract String getTestLinkNotes();
 public String toString() {
 return testId.toString() + " " + getExecutionStatus().name();
 }

 private String getTestDescription(Description description) {
 TestLink testLink = description != null ? description.getAnnotation(TestLink.class) : null;
 return testLink != null ? testLink.desc() : "No description";
 }

 }

 private static class Passed extends TestResult {

 Passed(TestId testId, Description description) {
 super(testId, description);
 }

 @Override
 public ExecutionStatus getExecutionStatus() {
 return ExecutionStatus.PASSED;
 }

 @Override
 public String getNotes() {
 return null;
 }

 @Override
 public boolean passed() {
 return true;
 }

 @Override
 public boolean failed() {
 return false;
 }

 @Override
 public String getTestLinkNotes() {
 StringBuilder sb = new StringBuilder(testId.id);
 sb.append(" '").append(testDescription).append("' PASSED.\n");
 return sb.toString();
 }

 }

 private static class Failed extends TestResult {
 public String reason;

 Failed(TestId testId, Failure failure) {
 super(testId, failure.getDescription());
 this.reason = failure.getMessage();
 }

 @Override
 public ExecutionStatus getExecutionStatus() {
 return ExecutionStatus.FAILED;
 }

 @Override
 public String getNotes() {
 return reason;
 }

 @Override
 public boolean passed() {
 return false;
 }

 @Override
 public boolean failed() {
 return true;
 }

 @Override
 public String getTestLinkNotes() {
 StringBuilder sb = new StringBuilder(testId.id);
 sb.append(" '").append(testDescription).append("' FAILED.\n");
 sb.append(reason);
 return sb.toString();
 }
 }
}

Det behövs också en testrunner som använder TestLinkReporter

package se.cygni.testlink;

import java.util.LinkedList;
import java.util.List;

import org.junit.runner.Description;
import org.junit.runner.Runner;
import org.junit.runner.manipulation.Filter;
import org.junit.runner.manipulation.NoTestsRemainException;
import org.junit.runner.notification.Failure;
import org.junit.runners.Suite;
import org.junit.runners.model.InitializationError;
import org.junit.runners.model.RunnerBuilder;

import se.cygni.testreport.AbstractReportingTestRunner;
import se.cygni.testreport.TestReporter;

public class TestLinkSuite extends Suite {

  private static TestReporter s_testReporter = new TestReporter() {

    @Override
    public void reportTestFailure(Failure failure) {}

    @Override
    public void reportTestSuccess(Description description) {}

    @Override
    public boolean testShouldBeRun(Description description) {
      return true;
    }
  };

  public static void setTestLinkReporter(TestLinkReporter testLinkReporter) {
    s_testReporter = testReporter;
  }

  public TestLinkSuite(Class<?> klass, RunnerBuilder builder) throws Throwable {
    super(klass, getRunners(getAnnotatedClasses(klass)));
    System.out.println(String.format("TestLinkSuite created for running test suite %s",klass.getSimpleName()));
    try {
      filter(new TestLinkFilter());
    } catch (NoTestsRemainException e) {
      System.out.println("No TestLink tests found in " + klass.getSimpleName());
    }
  }

  private static Class<?>[] getAnnotatedClasses(Class<?> klass) throws InitializationError {
    Suite.SuiteClasses annotation = klass.getAnnotation(Suite.SuiteClasses.class);
    if (annotation != null) {
      return annotation.value();
    }
    throw new InitializationError(String.format("class '%s' must have a SuiteClasses annotation", klass.getName()));
  }

  private static List getRunners(Class<?>[] classes) throws Throwable {
    List runners = new LinkedList();
    for (Class<?> klazz : classes) {
      runners.add(createRunner(klazz));
    }
    return runners;
  }

  private static Runner createRunner(Class<?> klazz) throws Throwable {
    return isSuite(klazz) ? new TestLinkSuite(klazz,null) : new TestLinkRunner(klazz);
  }

  public static boolean isSuite(Class<?> klazz) {
    return klazz.getAnnotation(Suite.SuiteClasses.class) != null;
  }

  /**
    *
    * Internal runner implementation
    *
   */
 private static class TestLinkRunner extends AbstractReportingTestRunner {

 public TestLinkRunner(Class<?> klass) throws Throwable {
 super(klass);
 System.out.println(String.format("TestLinkRunner created for running test class %s",klass.getSimpleName()));
 try {
 filter(new TestLinkFilter());
 } catch (NoTestsRemainException e) {
 System.out.println("No TestLink tests found in " + klass.getSimpleName());
 }
 }

 @Override
 protected TestReporter getTestReporter() {
 return s_testReporter;
 }
 }

 /**
 * Filter implementation that filters out
 * 1. test methods missing the TestLink annotation
 * 2. test classes that has no methods annotated with TestLink
 * 3. test suites that has no test classes containing methods annotated with TestLink
 */
 private static class TestLinkFilter extends Filter {

 @Override
 public boolean shouldRun(Description description) {
 if (isTestLinkMethod(description)) {
 return true;
 }
 for (Description each : description.getChildren()) {
 if (shouldRun(each)) {
 return true;
 }
 }
 return false;
 }

 private boolean isTestLinkMethod(Description description) {
 return description.isTest() && description.getAnnotation(TestLink.class) != null;
 }

 @Override
 public String describe() {
 return "TestLink";
 }
 }
}

Observera att TestLinkSuite ärver Suite, dvs skall användas för att exekvera en testsvit och inte enbart en enskild testklass. Denna begränsning är i praktiken inget problemet, om du mot all förmodan endast har en testklass som exekverar alla dina integrationstester så är det en smal sak att skapa en testsvit som inkluderar din enda testklass.

Annoteringen TestLink används för att annotera en testmetod, för vilken resultatet skall importeras in i TestLink.  Utöver att fungera som ”metodmarkör”, innehåller den också testfallsid och testfallsbeskrivning. Id används för att mappa testmetod mot testfall i TestLink medan beskrivningen används för att uppdatera noteringsfältet i TestLink.

package se.cygni.testlink;

import static java.lang.annotation.ElementType.METHOD;

import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Target({METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface  TestLink {
String id();
String desc() default "";
}

Nu återstår bara att fixa till en testsvit som exekveras av TestLinkSuite. Din testsvit måste också implementera en @BeforeClassmetod för att där skapa den ”globala” TestLinkReporter med uppgifter om projekt, testplan mm som skall uppdateras med testresultatet och injektas i TestLinkSuite.

Först en testklass med @TestLink-annoteringar för att indikera att testerna skall köras och att resultatet skall importeras in i TestLink

package se.cygni.testlink;

import static org.junit.Assert.*;

import org.junit.BeforeClass;
import org.junit.Test;
import org.junit.runner.RunWith;

import se.cygni.testreport.Calculator;

public class TestLinkCalculatorTest {

  @Test
  @TestLink(id="421", desc="Test addition")
  public void test_addition() {
   assertEquals(5,Calculator.add(2,3));
  }

  @Test
  @TestLink(id="422", desc="Test substraction")
  public void test_subtraction() {
    assertEquals(5,Calculator.subtract(8,2));
  }

}

Slutligen en testsvit som inkluderar ovanstående test och som exekveras av TestLinkSuite.

package se.cygni.testlink;

import org.junit.BeforeClass;
import org.junit.runner.RunWith;
import org.junit.runners.Suite.SuiteClasses;

@RunWith(TestLinkSuite.class)
@SuiteClasses(TestLinkCalculatorTest.class)
public class CalculatorTestSuite {
  @BeforeClass
  public static void beforeClass() {
    TestLinkReporter testLinkReporter = new TestLinkReporter(Configuration.getTestLinkProject(),Configuration.getTestPlan(),Configuration.getTestPlatform(),Configuration.getTestBuild());
    TestLinkSuite.setTestLinkReporter(testLinkReporter);
  }

}

Även om implementation ovan är specifikt riktad mot TestLink så är själva grundidén, dvs hur du designar dina egna testrunners och testklasser för att få till en rapportering av testresultatet generell och tillämplig även för andra testhanteringssystem än TestLink. Under förutsättning förstås att det finns ett användbart java-API!

Detta avslutar denna artikelserie om automatiserade integrationstester – kolla gärna in del 1 som handlar om parallelliserade tester eller del 2 som handlar om parametriserade tester.

Cygni-året 2012 inleddes med en Camel-föreläsning på konsultmötet i februari. I mars fick vi den klassiska kombinationen fisksoppa och guidad visning på Fotografiska museet. Någon vecka senare flög 37 Cygnianer till Champoluc för konfererande, umgänge och frisk alpluft. I april besökte Oracle vårt konsultmöte och snackade Java och i maj fick vi en dragning om responsive design följt av gemensamt hackande.

Eftersom Fotbolls-EM gick av stapeln i juni var temat för vår kundfest givet:

Bara ett par veckor efter kundfesten var det dags för sommarmiddag och på schemat stod segeltävling.

40-talet Cygnianer skulle, efter en summarisk genomgång av grundläggande seglingsprinciper, ge sig ut på en fjärd utanför Värmdö och utkämpa ett sjöslag. Kvällen avslutades inne på Södra Bar och som vanligt kom många Cygnianer inte hem förrän solen hade gått upp.

Hösten rivstartade med after work fredag 24 augusti följt av Bellmanstafetten dagen efter. Hårt schema för dem som var med på bägge aktiviteterna. Ett par veckor senare åkte vi ut till Fejan för kickoff och pokerprogrammeringstävling.

Konsultmötena under hösten har inkluderat highlights som Continuous Delivery, Solr och Neo4J. Det sista konsultmötet följde en gammal fin Cygni-tradition och innebar restaurangbesök på stan. Vi gick gruppvis och för första gången var den nya Cygni-gruppen Sirius ute tillsammans!

Julmiddagen på Berns, som Åsa fixat galant, tycker jag blev otroligt bra. Kombinationen av att både kunna hänga i den publika baren och att kunna sitta och snacka i ett chambre separée, var något jag tycker vi ska försöka få till fler gånger.

Under året har Cygnis första personalråd sett dagens ljus och jag är imponerad (men inte förvånad!) av hur seriöst och engagerat de tog sig an uppgiften.

De nya Cygnianer som vi haft förmånen att välkomna under året har redan gjort stort avtryck både internt och hos våra kunder. När vi nu går i mål för året gör vi det med full beläggning och har dessutom 8 underkonsulter i uppdrag. Och blickar vi framåt mot nästa år så fortsätter det att se oerhört bra ut.

Sjunde mars åker vi till Grindelwald för att konferera. Denna ort är paragliding-stället #1 i Schweiz och alla Cygnianer som vill kommer att få möjlighet att testa på. Letandet efter ett nytt och större kontor fortsätter 2013. För några veckor sedan trodde jag att vi hade ett kontor vid Slussen på gång men tydligen låg ett annat företag före oss i processen. Det vi söker efter är en lokal som ligger bra till kommunikationsmässigt dvs nära centralen eller slussen.

Den 1 februari skapas också en ny konsultgrupp på Cygni – Sirius. Som ni vet är det Per som kommer ta rollen som konsultchef och jag är väldigt förhoppningsfull inför detta.

Precis som förra året delar vi inte ut några fysiska julklappar på Cygni. Istället skänker vi 50.000 kr till BRIS. Surfa gärna in på www.brisstodforetag.se och läs om vad Cygnis pengar bidrar till!

Väl mött Cygni-året 2013!