Poster taggade med ‘eclipse’

Sida 1/5:12345

I den här artikeln ska jag skriva lite om EclEmma, en plugin till Eclipse för testramverket EMMA. Pluginen är inte på något sätt ny, men inte desto mindre användbar. Verktyget är till för att visa dig hur väl dina tester täcker din kod, s. k. test coverage.

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

Detta är den sista delen av tre i en artikelserie om automatiserade integrationstester. Den första delen ger en kort beskrivning av syftet med integrationstester och de utmaningar som ofta uppstår vid testning. Där visar jag också hur man kan parallellisera tester i JUnit för att minska exekveringstiden.

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. Läs mer >>

Detta är den andra delen av tre i en artikelserie om automatiserade integrationstester. Den första delen ger en kort beskrivning av syftet med integrationstester och de utmaningar som ofta uppstår vid testning. Där visar jag också hur man kan parallellisera tester i JUnit för att minska exekveringstiden.

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

Den sista delen visar hur man kan koppla ihop sina testsviter med open source-verktyget TestLink för att få fram trevliga rapporter. Läs mer >>

När man skall skriva automatiserade integrations- eller regressionstester ställs man delvis inför lite andra utmaningar än vad som gäller för ”vanliga” enhetstester. Detta är den första delen av tre i en artikelserie om automatiserade integrationstester. Denna första del ger en kort beskrivning av syftet med integrationstester och de utmaningar som ofta uppstår vid testning. Där visar jag också hur man kan parallellisera tester i JUnit för att minska exekveringstiden.

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

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

Läs mer >>

Det finns mängder av artiklar här på Stacktrace som handlar om Eclipse. Jag tänkte samla ihop några godbitar som fortfarande känns relevanta.

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

Här beskriver jag hur man snabbt och enkelt kan sätta upp en jee-applikation (ear, webapp- och ejb-modul) på några få minuter genom att använda sig av Maven-arketyper ifrån org.codehaus.mojo.archetypes och kommandot mvn archetype:generate. Vi tar också användning av eclipse m2e-plugin för att uppdatera beroenden mellan ear och web/ejb-modulerna.

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.

Eclipse plockar per default det inloggade namnet och sätter i @author-taggen i all javadoc som man skriver. Jag personligen vill oftast att mitt riktiga namn skrivs där istället. Ett sätt att få till det är att man editerar code templates, Inställningar -> Java -> Code Style -> Code Templates. Detta känns ju inte helt optimalt så istället brukar jag editera eclipse.ini filen och lägga till följande fetmarkerade variabel:

-Xms256m

-Xmx1024m

-Duser.name=Anders Hedström

och vips så plockar Eclipse upp det värdet när jag skapar ny javadoc

Om man utvecklar Android-appar på Windows och vill ansluta en Android-enhet till datorn för att testa apparn så måste man installera Android’s Windows USB-drivrutin. Jag läste och följde alla instruktioner på Android’s utvecklarsidor och försökte ansluta min HTC Hero….men det gick inte alls, jag kunde inte ens installera drivrutinerna på datorn som kör Windows XP.

Vad jag fick göra istället var att ladda ner HTC Sync och installera den mjukvaran på datorn, sen så pluggade jag in telefonen och då kände adb att min telefon var ansulten till datorn och jag kunde utan problem köra mina appar från Eclipse direkt på min telefon.

Läste på InfoQ att en första publik version av EGit har releasats. EGit är en Eclipse-plugin för Git som vi tidigare diskuterat här på Stacktrace.

Se våra tidigare inlägg om Git-tricks eller en mer utförlig artikel om Distribuerad versionshantering med Git.

Jag har testat EGit och den funkar bra. Dock föredrar jag personligen att använda prompten/shellet för push, pull, branch och commit men EGit medför dock att det blir väl synligt i Eclipse vilka filer som inte är versionshanterade, vilka filer som är modifierade etc.

Sida 1/5:12345