Automatisierte Akzeptanz-Tests mit JBehave

5 Kommentare

Einleitung

Im Open Source Bereich haben agile Teams mittlerweile die Auswahl zwischen einer Vielzahl von Werkzeugen für die Automatisierung von Akzeptanz-Tests. Dabei gibt es eine ganze Reihe unterschiedlicher Konzepte. FitNesse setzt für die Organisation der Testfälle z.B. auf ein integriertes Wiki, wohingegen das Robot Framework auf Keyword-getriebene Testentwicklung setzt, um hier einmal zwei der bekannteren Vertreter dieser Gattung zu nennen. Diese Werkzeuge bieten einen sehr großen Funktionsumfang, erfordern aber auch ein Stück weit mehr Einarbeitungszeit.

JBehave wirkt hier im Vergleich auf den ersten Blick (und auch auf den zweiten Blick) sehr schlank. Da gibt es auf der einen Seite die Testbeschreibungen im BDD-Format und auf der anderen Seite die Implementierung der Testfunktionalität in Java. Beides lässt sich leicht miteinander verbinden und dann mittels Maven ausführen.

Aufgrund der Länge dieses Artikels hier ein kurzer Überblick über die im Folgenden behandelten Themen:

  • Maven-Konfiguration: Erläutert die notewendige Maven-Konfiguration für die Implementierung und Ausführung von Tests mit JBehave.
  • Testbeschreibung: Zeigt wie Tests in JBehave mit Hilfe des BDD-Formats geschrieben werden.
  • Testimplementierung: Beschreibt die notwendigen Implementierungs-Schritte (in Java), um eine Testbeschreibung mit Leben zu füllen.
  • Reporting: Aufbereitung der Testresultate durch JBehave.
  • Zusammensetzen der Einzelteile: Maven, Testbeschreibung und Testimplementierung werden über bestimmte Namenskonventionen und Verzeichnisse zusammengefügt.
  • Fazit: Wie gut lassen sich Akzeptanz-Tests mit JBehave automatisieren? Für wen eignet sich das Werkzeug?
  • Download: Hier können alle Dateien aus dem Beispiel als ZIP-Datei heruntergeladen werden.

Logbuch Nachtrag vom 16.06.2012: Mein Kollege Andreas hat einen sehr ausführlichen Artikel über die diversen Konfigurationsmöglichkeiten von JBehave geschrieben, der sicherlich hilfreich ist nach dem Start :).

Maven-Konfiguration

Für Projekte im Java-Umfeld hat JBehave definitiv den großen Vorteil, dass eine Einbindung in die bereits vorhandene Entwicklungs-Umgebung des Teams sehr nahtlos funktioniert. Insbesondere wenn Maven bereits als Build-System im Einsatz ist. Bei anderen Werkzeugen funktioniert dies natürlich auch. Es sind hierbei jedoch oft kleinere oder größere Verrenkungen notwendig. Dies ist besonders dann der Fall, wenn die Werkzeuge initial in einer anderen Programmiersprache entwickelt wurden (und werden) und erst nachträglich um eine Unterstützung für Java erweitert werden.

Die folgende Maven-Konfiguration ist ausreichend, um mit der Entwicklung neuer Akzeptanz-Tests in JBehave zu starten und darüber hinaus später auch die notwendigen Artefakte herunterzuladen, welche für das Reporting benötigt werden:

<?xml version="1.0" encoding="UTF-8"?>
 
<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">
 
  <url>http://maven.apache.org</url>
  <modelVersion>4.0.0</modelVersion>
  <name>JBehaveDemo</name>
 
  <groupId>de.codecentric</groupId>
  <artifactId>jbehave-demo</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
 
  <dependencies>
    <dependency>
      <groupId>org.jbehave</groupId>
      <artifactId>jbehave-core</artifactId>
      <version>3.1.2</version>
    </dependency>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.4</version>
    </dependency>
  </dependencies>
 
  <build>
    <plugins>
 
      <plugin>
        <groupId>org.jbehave</groupId>
        <artifactId>jbehave-maven-plugin</artifactId>
        <version>3.1.2</version>
        <executions>
          <execution>
            <id>run-stories-as-embeddables</id>
            <phase>integration-test</phase>
            <configuration>
              <includes>
                <include>**/*Scenarios.java</include>
              </includes>
              <ignoreFailureInStories>true</ignoreFailureInStories>
              <ignoreFailureInView>false</ignoreFailureInView>
           </configuration>
           <goals>
              <goal>run-stories-as-embeddables</goal>
           </goals>
         </execution>
       </executions>
     </plugin>
 
     <plugin> 
       <groupId>org.apache.maven.plugins</groupId> 
       <artifactId>maven-dependency-plugin</artifactId> 
       <executions> 
         <execution> 
            <id>unpack-jbehave-site-resources</id>
            <phase>generate-resources</phase> 
            <goals> 
               <goal>unpack</goal> 
            </goals> 
            <configuration> 
               <overwriteReleases>false</overwriteReleases> 
               <overwriteSnapshots>true</overwriteSnapshots> 
               <artifactItems> 
                  <artifactItem> 
                     <groupId>org.jbehave.site</groupId> 
                     <artifactId>jbehave-site-resources</artifactId> 
                     <version>3.1.1</version> 
                     <type>zip</type>
                     <outputDirectory> ${project.build.directory}/jbehave/view</outputDirectory> 
                   </artifactItem> 
                </artifactItems> 
            </configuration> 
         </execution> 
         <execution> 
            <id>unpack-jbehave-reports-resources</id>
            <phase>generate-resources</phase> 
            <goals> 
               <goal>unpack</goal> 
            </goals> 
            <configuration> 
              <overwriteReleases>false</overwriteReleases> 
              <overwriteSnapshots>true</overwriteSnapshots> 
              <artifactItems> 
                 <artifactItem> 
                   <groupId>org.jbehave</groupId> 
                   <artifactId>jbehave-core</artifactId> 
                   <version>3.1.2</version> 
                   <outputDirectory>${project.build.directory}/jbehave/view</outputDirectory> 
                   <includes>**\/*.css,**\/*.ftl,**\/*.js</includes> 
                 </artifactItem> 
               </artifactItems> 
             </configuration> 
           </execution> 
         </executions> 
       </plugin> 			
     </plugins>
 
  </build>
</project>

Mit dieser Maven-Konfiguration werden nicht nur alle benötigten JAR-Dateien direkt heruntergeladen, sondern die Tests können auch direkt mittels „mvn integration-test“ ausgeführt werden. Hierzu benötigen wir aber natürlich noch eine Testbeschreibung und die zugehörige Implementierung.

Testbeschreibung

Testbeschreibungen werden in JBehave mit Hilfe der weit verbreiteten Given/When/Then-Syntax (BDD-Format) geschrieben. Dieses Format sieht wie folgt aus:

Given:Eine statische Vorbedingung
And:Eine weitere statische Vorbedingung
And:
When:Das zu testende Verhalten
And:Das weitere zu testende Verhalten
And:
Then:Das Ergebnis des Verhaltens unter den gegebenen Vorbedingungen
And:

Das BDD-Format hat den Vorteil, dass es auch von fachlichen Mitarbeitern gut gelesen werden kann. Dies ermöglicht ein gemeinsames Verständnis über die Tests zwischen dem Entwicklungsteam und dem Fachbereich/Kunden.

Das Schreiben von automatisierten Akzeptanz-Tests ist eine Aufgabe, die idealerweise in enger Zusammenarbeit zwischen fachlichen Experten und dem agilen Entwicklungsteam geschieht. Dies garantiert, dass alle notwendigen Kompetenzen vorhanden sind und ggf. erste Ergebnisse einer Test-Umsetzung schnell gemeinsam geprüft werden können. Eine für alle Beteiligten verständliche Beschreibung der Tests ist dabei natürlich eine Grundvoraussetzung.

In JBehave werden die Tests in sogenannten Story-Dateien beschrieben. Dabei ist es eine sinnvolle Konvention, dass in einer Story-Datei die Tests für eine User-Story beschrieben werden. Bereits für die Implementierung wird darauf geachtet, dass eine einzelne User-Story nicht zu umfangreich wird. Dies wird im Normalfall auch dazu führen, dass die Anzahl der Testfälle – in JBehave Scenarios genannt – überschaubar bleibt. Dies wird durch die sehr klare Struktur der Story-Dateien in JBehave zusätzlich unterstützt.

Um unser Beispiel möglichst einfach zu halten testen wir die vorhandene Stack-Implementierung von Java. Dies ermöglicht ein gutes Verständnis des Anwendungsfalls und auch der später benötigte Testcode bleibt übersichtlich, da es hier ja hauptsächlich um die Konzepte und Zusammenhänge gehen soll.

Narrative:
In order to develop an application that requires a stack efficiently
As a development team
I would like to use an interface and implementation in Java directly
 
Scenario:  Basic functionality of a Stack
 
Given an empty stack
When the string Java is added
And the string C++ is added
And the last element is removed again
Then the resulting element should be Java
 
Scenario:  Stack search
 
Given an empty stack
When the string Java is added
And the string C++ is added
And the string PHP is added
And the element Java is searched for
Then the position returned should be 3

Am Anfang einer Story-Datei ist es möglich die getestete User-Story noch einmal zu beschreiben. Dies erfolgt nach dem Schlüsselwort Narrative:. Dabei bietet es sich natürlich an die Formulierung aus einer – hoffentlich bereits vorhandenen – User-Story zu übernehmen. Da dieser Text jedoch für den Test vollständig ignoriert wird, kann hier letzten Endes beliebiger Text stehen.

Gerade bei Tests im BDD-Format ist es sehr sinnvoll, dass diese in der eigenen Muttersprache geschrieben werden. In obigem Beispiel sind die Tests in Englisch geschrieben worden, da dies der Standard in JBehave ist. Es ist jedoch möglich durch die Implementierung einer zusätzlichen Klasse auf der Java-Seite die Schlüsselwörter auch in anderen Sprachen zu nutzen, z.B. Gegeben/Wenn/Dann.

Danach können beliebig viele Szenarien (=Testfälle) in BDD-Notation angegeben werden. Diese werden mit dem Schlüsselwort Scenario: eingeleitet. Danach folgt direkt in derselben Zeile eine kurze textuelle Beschreibung des Testfalls. Dann erfolgt die eigentliche Definition des Tests.

Testimplementierung

Das Mapping der Testbeschreibung auf die entsprechenden Testmethoden ist denkbar einfach. Jede Zeile in der Testbeschreibung (in JBehave sind dies Schritte/Steps) entspricht einer Methode in einer Testklasse, welche mit einer entsprechenden JBehave-Annotation markiert ist. Die Übergabe der Parameter erfolgt durch eine Namenskonvention ($variable) in den Annotationen. Diese müssen dann auch als Parameter in der Methode definiert sein.

package de.codecentric.jbehave;
 
import java.util.Stack;
import org.jbehave.core.annotations.*;
import org.jbehave.core.embedder.Embedder;
import junit.framework.Assert;
 
public class StackStories extends Embedder{
 
    private Stack testStack;
    private String searchElement;
 
    @Given("an empty stack")
    public void anEmptyStack() {
        testStack = new Stack();
    }
 
    @When("the string $element is added")
    public void anElementIsAdded(String element) {
        testStack.push(element);
    }
 
    @When("the last element is removed again")
    public void removeLastElement() {
        testStack.pop();
    }
 
    @When("the element $element is searched for")
    public void searchForElement(String element) {
        searchElement = element;
    }
 
    @Then("the resulting element should be $result")
    public void theResultingElementShouldBe(String result) {
    	Assert.assertEquals(testStack.pop(), result);
    }
 
    @Then("the position returned should be $pos")
    public void thePositionReturnedShouldBe(int pos) {
    	Assert.assertEquals(testStack.search(searchElement), pos);
    }
}

Die oben angegebene Klasse beinhaltet die sogenannten Schritte (Steps) aus der Testbeschreibung. Damit die Tests aus einer Story-Datei ausgeführt werden können wird noch eine weitere Klasse benötigt. Diese stellt über eine Namenskonvention die Verbindung zu der Story-Datei her und definiert des weiteren wie z.B. das Reporting erfolgen soll:

package de.codecentric.jbehave;
 
import java.net.MalformedURLException;
import java.net.URL;
import java.util.List;
 
import org.jbehave.core.configuration.Configuration;
import org.jbehave.core.configuration.MostUsefulConfiguration;
import org.jbehave.core.io.LoadFromRelativeFile;
import org.jbehave.core.junit.JUnitStory;
import org.jbehave.core.reporters.StoryReporterBuilder;
import org.jbehave.core.reporters.StoryReporterBuilder.Format;
import org.jbehave.core.steps.CandidateSteps;
import org.jbehave.core.steps.InstanceStepsFactory;
import org.junit.Test;
 
public class StackScenarios extends JUnitStory {
 
    @Override
    public Configuration configuration() {
        URL storyURL = null;
        try {
            // This requires you to start Maven from the project directory
            storyURL = new URL("file://" + System.getProperty("user.dir")
                    + "/src/main/resources/stories/");
        } catch (MalformedURLException e) {
            e.printStackTrace();
        }
        return new MostUsefulConfiguration().useStoryLoader(
                new LoadFromRelativeFile(storyURL)).useStoryReporterBuilder(
                new StoryReporterBuilder().withFormats(Format.HTML));
    }
 
    @Override
    public List candidateSteps() {
        return new InstanceStepsFactory(configuration(), new StackSteps())
                .createCandidateSteps();
    }
 
    @Override
    @Test
    public void run() {
        try {
            super.run();
        } catch (Throwable e) {
            e.printStackTrace();
        }
    }
}

Die API von JBehave bietet noch einige weitere Möglichkeiten. Die obigen Klassen sind aber im Prinzip ausreichend um mit dem Testen zu starten. Ein Kritikpunkt hier ist definitiv die sehr schlechte JavaDoc-Dokumentation der API-Klassen.

Ein positiver Punkt ist, dass es nicht notwendig ist für jeden Schritt in der Testbeschreibung auch sofort eine Implementierung in Form einer passenden Methode bereit zu stellen. JBehave kann damit umgehen, dass die Implementierung der Schritte noch fehlt und markiert bei der Ausführung diese Schritte dann per Default als „Pending“ im Report. Auf diese Art und Weise ist es möglich die Testbeschreibungen bereits fertig zu stellen ohne auch sofort eine Implementierung (sei es auch nur in einer Dummy-Form) anzufertigen. Das Verhalten von JBehave in dieser Situation ist jedoch konfigurierbar und wenn es Sinn macht, kann eine fehlende Implementierung auch sofort als Fehler gewertet werden.

Natürlich ist es äußerst hilfreich wenn die Tests auch aus einer IDE (z. B. Eclipse) heraus ausgeführt werden können. Dies funktioniert bei JBehave sehr einfach, denn diese unscheinbare Methode in obiger Klasse:

...
    @Override
    @Test
    public void run() {
        try {
            super.run();
        } catch (Throwable e) {
            e.printStackTrace();
        }
    }
...

macht es möglich die Tests direkt mittels JUnit auszuführen. Auf diese Möglichkeit bin ich eher zufällig beim Herumprobieren gestoßen, da ich dies nicht so explizit in der Dokumentation gefunden habe (oder es schlicht übersehen habe). So können die Test bei Bedarf z. B. sehr einfach im Debugger ausgeführt werden.

Reporting

Der folgende Screenshot zeigt den von JBehave erzeugten Report für die Ausführung der Tests:

Der Informationsgehalt ist nicht überragend aber ausreichend. Insbesondere ist das in dieser Art Report wichtige Erstellungsdatum in der Fußzeile vorhanden . Die beiden Links am Ende führen einmal zu einer Seite mit dem Inhalt der Story-Datei und zu einer textuellen Ansicht der Statistiken. Die gesamte Konfiguration des Reportings bietet noch weitere Möglichkeiten, aber da es hier erstmal um einen Überblick geht, soll dies für den Augenblick reichen.

Der Report selber findet sich nach der Testausführung im Eclipse-Workspace unter target/jbehave/view und heißt reports.html. Damit die Reports ansprechend aussehen, werden noch eine ganze Reihe Style-Dateien benötigt. Wir haben in der POM-Datei aber ja schon alle Einträge gemacht, um diese komfortabel mittels:

mvn generate-resources

herunterzuladen. Hiernach sollten im target/jbehave/view-Verzeichnis eine Reihe von Unterverzeichnissen auftauchen (ftl, images, …).

Zusammensetzen der Einzelteile

Für die Implementierung der Akzeptanz-Tests gibt es drei relevante Teile:

  • Maven-Konfiguration: Diese ist im Prinzip statisch, nachdem das Ganze einmal funktioniert.
  • Testbeschreibungen: Hier kommen für jede neue User-Story neue Story-Dateien hinzu. Ggf. werden bestehenden Szenario-Beschreibungen geändert oder erweitert.
  • Testimplementierung: Die Java-Klasse zum ansteuern der Tests ist eher statisch und für das Einbinden weiterer Stories würde hier wohl eine Basisklasse viel Sinn machen. Die Implementierung der eigentlichen Testschritte erfolgt parallel zur Entwicklung der Testbeschreibungen. Hier liegt die eigentliche Logik der Tests.

Es gibt einige Namenskonventionen, welche aufeinander abgestimmt werden müssen. So definiert der folgende Abschnitt aus der POM-Datei, welche Java-Klassen als Scenarios ausgeführt werden:

   ...
          <execution>
            <id>run-stories-as-embeddables</id>
            <phase>integration-test</phase>
            <configuration>
              <includes>
                <include>**/*Scenarios.java</include>
              </includes>
              <ignoreFailureInStories>true</ignoreFailureInStories>
              <ignoreFailureInView>false</ignoreFailureInView>
           </configuration>
           <goals>
              <goal>run-stories-as-embeddables</goal>
           </goals>
         </execution>
   ...

Anhand des Namens der „Scenario-Klasse“ – in diesem Fall StackScenarios.java – wird dann die passende Story-Datei gefunden. Diese muss den entsprechenden Namen haben, darf sich aber mit Unterstrichen und bei der Groß-/Kleinschreibung unterscheiden. In unserem Beispiel hat die Story-Datei den Namen stack_scenarios.story.

JBehave bietet verschiedene Möglichkeiten für die Suche nach den Story-Dateien. In unserem Beispiel geschieht dies einfach über einen absoluten Pfad, welcher das aktuelle Verzeichnis beinhaltet. Daher müssen die Tests aus dem Projekt-Verzeichnis ausgeführt werden. Dem Namen der Story-Datei wird als Pfad noch das Java-Package in dem sich die Scenario-Klasse befindet vorangestellt. Dies muss beim Speicherort der Story-Dateien bedacht werden.

In der Scenario-Klasse wird dann in der folgenden Methode definiert, in welcher Klasse (oder Klassen) sich die Schritt-Definitionen finden:

...
    @Override
    public List candidateSteps() {
        return new InstanceStepsFactory(configuration(), new StackSteps())
                .createCandidateSteps();
    }
...

Die entsprechenden Klassen müssen über den Klassenpfad erreichbar sein, wobei man sich wohl schon anstrengen müsste, damit dies nicht der Fall ist.

Fazit

Bei der Länge dieses Artikels könnte der Verdacht aufkommen, dass es mit der in der Einleitung versprochenen Leichtgewichtigkeit doch nicht soweit her ist. Dies stimmt aber nicht, da das Beispiel sicherlich ca. 80%-90% der benötigten Rahmen-Implementierung beinhaltet, um mit einer Akzeptanz-Testsuite zu starten. Der Aufwand für die Implementierung spezieller Testfunktionalität hängt natürlich stark von deren Komplexität ab. Dies ist aber unabhängig vom eingesetzten Werkzeug immer der Fall. Ein Vorteil ist, dass Java-Entwickler mit JBehave vermutlich gut abschätzen können, was bereits durch bestehende Java-Bibliotheken gut unterstützt wird und wo mehr Aufwand in das Schreiben des Testcodes fließen muss.

Der Aufbau der Story-Dateien ist simpel und sauber und auch gibt es hier noch weitere Möglichkeiten wie z.B. die Nutzung von Test-Tabellen, um gewisse Szenarien mehrfach mit verschiedenen Testwerten zu durchlaufen. Auch ist es möglich durch Meta-Anweisungen in den Story-Dateien das Reporting zu beeinflussen, wenn dies gewünscht ist. Das Reporting wirkt auf den ersten Blick ausreichend und ist laut Dokumentation über weitere Konfiguration noch erweiterbar.

Die einfache Integration mit Maven und Eclipse ist eine große Stärke von JBehave und spricht sicherlich insbesondere Java-Entwickler sehr an. Die einfache Ausführung der Tests mittels JUnit (z. B. fürs Debugging) ist hier eine weiterer Pluspunkt.

Die Integration in eine CI-Umgebung (Kontinuierliche Integration) ist dank Maven problemlos möglich. Das Testen von Web-Anwendungen wird über eine eigene JBehave Web-Komponente unterstützt, welche auf Selenium aufsetzt oder man benutzt direkt die Java-Implementierung von Selenium.

Mein persönliches Fazit: Der Einstieg in JBehave macht Spaß und bietet recht wenig Frust-Momente (hauptsächlich beim Blick in die API-Dokumentation). Auch wenn ich nicht der größte Maven-Fan bin, so ist die Integration mit Maven hier schon sehr gut gelungen und hilfreich. Den Einsatz dieses Werkzeugs in einem echten Projekt könnte ich mir gut vorstellen. Natürlich gibt es noch einige weitere Dinge zu entdecken (Unterstützung anderer Sprachen in den Story-Dateien und Web-Testing wären für mich dabei die wichtigsten), welche hoffentlich in einem weiteren Blog-Beitrag noch genauer betrachtet werden können.

Download

Hier können alle benötigten Dateien für das Beispiel aus diesem Artikel als ZIP-Datei herunter geladen werden, um es z.B. in Eclipse zu importieren.

cc_JBehaveSample.zip

Das Projekt muss dann mit dem folgenden Kommando gebaut werden:

mvn compile

Die benötigten Style-Dateien für das Reporting können einmalig mittels des folgenden Kommandos erzeugt werden:

mvn generate-resources

Danach können die Tests wie folgt ausgeführt werden:

mvn integration-test

Alle Kommandos müssen aus dem Projekt-Verzeichnis ausgeführt werden in dem auch die pom.xml-Datei liegt.

Thomas Jaspers

Langjährige Erfahrung in agilen Softwareprojekten unter Einsatz von Java-Enterprise-Technologien. Schwerpunkt im Bereich der Testautomatisierung (Konzepte und Open-Source Werkzeuge).

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Thomas Jaspers

    Happy to hear you like it and the „generate-resources“ goal is quite handy indeed.

    Thanks for the hint with the Hudson/Jenkins-PlugIn. I am planning to have a follow-up post on this one with kind of advanced topics and the PlugIn is a good feature to look at for this.

  • Thomas Jaspers

    I cannot say for sure, but I doubt that this is possible in the story-files as such. It is also the question if you really would like to call the complete scenario or just the preconditions (Given) and behaviour (When).

    Do you have a more concrete example for this?

    What I could imagine anyway is that you make one scenario a kind of precondition for another scenario by creating a new Given-clause and in the implementation of that one on the Java-side you can then call the already existing methods and reusing them this way.

  • Thomas Jaspers

    You mean the report.html file under …\target\jbehave\view?

  • Thomas Jaspers

    Hi Kotresh,

    I have not tried this on my own, as I am not using TestNG. Unfortunetly your code example is lost from the post, but here is what I found from JBehave FAQ pages (http://jbehave.org/reference/legacy/faq.html).

    Hope this helps :-).

    Cheers
    – Thomas

    Can I run my scenarios in IDE with TestNG?

    Similarly to the proposed workaround above, you should be able to run with TestNG by simply annotating the runScenario() method in your root Scenario class with the TestNG @Test annotation.

    public class YourScenario extends JUnitScenario {
     
        @org.testng.annotations.Test
        public void runScenario() throws Throwable {
            super.runScenario();
        }
     }

    Note that as we don’t tend to use TestNG this solution has not been well-tested. If you encounter any issues please let us know.

  • Christian

    15. April 2014 von Christian

    Hi Thomas,

    Everytime I’m getting:
    Reports view generated with 0 stories (of which 0 pending) containing 0 scenarios (of which 0 pending)

    The tests are green and executed. But in the report file, every number is zero.

    I downloaded your example. The only thing I changed is the
    @RunWith(JUnitReportingRunner.class).

    Do you know where the error is?

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.