2016-07-23 20 views
0

In meinem Testfall müssen mehrere Assertionen verwendet werden. Problem ist, dass wenn eine Assertion fehlschlägt, die Ausführung beendet wird. Ich möchte, dass dieser Testfall auch nach dem Auftreten eines Assertionsfehlers weiterhin ausgeführt wird und alle Assertionsfehler nach der Ausführung angezeigt werden.Fortsetzung der Ausführung, selbst wenn die Assert-Anweisung in Selen mit Junit 4-Framework fehlschlägt

Zum Beispiel:

assertTrue("string on failure",condition1); 
assertTrue("string on failure",condition2); 
assertTrue("string on failure",condition3); 
assertTrue("string on failure",condition4); 
assertTrue("string on failure",condition5); 

Hier in diesem Beispiel möchte ich, dass, wenn assert für condition2 ausfällt, dann sollte es auch weiterhin alle Ausfälle nach der vollständigen Ausführung auszuführen und zu zeigen.

Antwort

1

Die Funktion, die Sie suchen ist Soft-Assertion genannt, versuchen Sie bei Ausfall der Ausführung mit dem nächsten Schritt ermöglichen, ohne zu werfen Ausnahme assertj

SoftAssertions soft = new SoftAssertions(); 
    soft.assertThat(<things>).isEqualTo(<other_thing>); 
    soft.assertAll(); 

Soft-Assertion wird. Am Ende assertAll() Methode mit allen gesammelten Fehler bei onece.

+0

Aber ist dies in Junit anwendbar .... Ich dachte, das ist Testng Zeug –

+0

AssertJ hat JUnit als Abhängigkeit (https://mvnrepository.com/artifect/org.assertj/assertj-core/3.5.1), so sollte es funktionieren Es sammelt nur die Ausnahmen und erbricht einfach alles auf einmal, wenn es eins bekommt. Das Konzept ist definitiv nicht mit irgendeinem Unit Test Framework oder Sprache verbunden. In der Tat ist hier die Implementierung von Soft-Assert in Python (http://pythontesting.net/strategy/delayed-assert), es ist genau das, was @ Jeremiah vorgeschlagen hat. – pr4bh4sh

4

Verwenden Sie für eine reine JUnit-Lösung den ErrorCollector TestRule, um Ihre Anforderungen zu erfüllen.

Der ErrorCollector Regel erst zurück, wenn die Testausführung abgeschlossen ist.

import org.hamcrest.core.IsEqual; 
import org.hamcrest.core.IsNull; 
import org.hamcrest.text.IsEmptyString; 
import org.junit.Rule; 
import org.junit.Test; 
import org.junit.rules.ErrorCollector; 

public class ErrorCollectorTest { 
    @Rule 
    public ErrorCollector collector = new ErrorCollector(); 

    @Test 
    public void testMultiAssertFailure() { 
     collector.checkThat(true, IsEqual.equalTo(false)); 
     collector.checkThat("notEmpty", IsEmptyString.isEmptyString()); 
     collector.checkThat(new Object(), IsNull.nullValue()); 
     collector.checkThat(null, IsNull.notNullValue()); 

     try { 
      throw new RuntimeException("Exception"); 
     } catch (Exception ex){ 
      collector.addError(ex); 
     } 
    } 
} 

In Ihrem speziellen Beispiel:

assertTrue("string on failure",condition1); 
assertTrue("string on failure",condition2); 
assertTrue("string on failure",condition3); 
assertTrue("string on failure",condition4); 
assertTrue("string on failure",condition5); 

würde

Matcher<Boolean> matchesTrue = IsEqual.equalTo(true); 
collector.checkThat("String on Failure", condition1, matchesTrue); 
collector.checkThat("String on Failure", condition2, matchesTrue); 
collector.checkThat("String on Failure", condition3, matchesTrue); 
collector.checkThat("String on Failure", condition4, matchesTrue); 
collector.checkThat("String on Failure", condition5, matchesTrue); 
0

Die andere Option hier geworden ist eine bewährte Methode, dass viele Leute sagen, dass Sie immer sowieso tun sollten: Nur setzen ein in jedem Testfall geltend machen.

Dadurch ist jeder potenzielle Fehler irgendwie voneinander isoliert; und Sie erhalten direkt, was Sie suchen - wie JUnit Ihnen genau sagen wird, welche Tests fehlgeschlagen sind und welche bestanden haben. Ohne die Notwendigkeit, andere Konzepte einzuführen.

(Sie sehen, selbst wenn diese anderen Begriffe wie ErrorCollector oder SoftAssertions sind recht einfach und unkompliziert zu bedienen - sie ein wenig Komplexität, um Ihren Code hinzufügen, so dass es ein bisschen schwerer zu lesen und zu verstehen)

+1

In einem * Einheit * Test ist es am besten, nur eine Aussage pro Test zu machen. Mit Tools wie Selenium wird der Test nicht mehr als Einheitstest durchgeführt, da er gegen ein Live-System laufen muss. Dies ist ein "Integrationstest". Auf der Integrationsebene des Tests hat der Wunsch, Validierungen zu isolieren, oft einen Preis (Zeit/Leistung/Feedback), was die Multi-Assert-Einrichtungen akzeptabler macht. Es dreht sich alles um den Kontext, auf den sich der Test bezieht.Ich stimme nicht mit Ihrer Aussage in Bezug auf Unit-Tests, aber mit der Integration ist diese Regel nicht standhaft (in meiner Erfahrung) – Jeremiah

+0

ya .. Ich dachte auch darüber nach .. Aber in vielen Situationen wie UI von kleinen Abschnitt zu überprüfen (für Beispiel-Login-Seite), macht mehrere Behauptungen Sinn. Über die vorgeschlagenen Lösungen hinaus werden nur 1 oder 2 Codezeilen anstelle von viel Komplexität hinzugefügt –