Ist es möglich, JUnit-Testfälle und Suiten programmatisch zu generieren?

Question

Ich habe eine sehr großen Test-Suite für eine komplexe Reihe von Geschäftsregeln zu schreiben, die derzeit in mehreren tabellarischen Formen erfaßt werden (zum Beispiel, wenn die Parameter X Y Z so und so ist, soll der Wert zwischen V1 und V2). Jede Regel hat einen Namen und eine eigene Semantik.

Mein Endziel ist es, eine Test-Suite zu haben, in Teiltestsuiten organisiert, mit einem Testfall für jede Regel.

Eine Option ist, um tatsächlich hart Code all diese Regeln als Tests. Das ist hässlich, zeitraubend und unflexibel.

Ein weiterer Grund ist ein Python-Skript zu schreiben, die die Regeldateien und erzeugen Java-Klassen mit den Unit-Tests lesen würde. Ich würde lieber vermeiden dies, wenn ich kann. Eine weitere Variante wäre Jython zu verwenden.

Idealerweise würde aber Ich mag eine Test-Suite haben, der die Dateien lesen würde und dann Unter Suiten und Tests in ihnen definieren. Jeder dieser Tests kann mit bestimmten Werten aus den Tabellendateien genommen initialisiert werden, feste Eintrittspunkte in unserem System laufen, und rufen Sie dann eine Prüffunktion auf die Ergebnisse basierend auf dem erwarteten Wert.

Gibt es eine vernünftige Möglichkeit, dies abziehen nur mit Java?

Update: Ich unsere Art von Regeln etwas vereinfacht haben. Einige von ihnen sind in der Tat tabellarisch (Excel-Stil), andere sind eher unscharf. Die allgemeine Frage aber bleibt, wie ich bin wahrscheinlich nicht die erste Person, die dieses Problem hat.

Answer 1

Innerhalb von JUnit 4 Sie werden auf der Parameterized Läufer aussehen wollen . Es wurde zu dem Zweck geschaffen, um Sie (data driven Tests) beschreiben. Sie werden nicht in Suiten organisieren jedoch.

In Junit 3 Sie können programmatisch Testsuiten und Tests erstellen. Die Antwort ist in Junit Rezepte , die ich erweitern können, wenn Sie es brauchen (denken Sie daran, dass JUnit 4 laufen kann junit 3 Tests).

Answer 2

Haben Sie mit in Betracht gezogen FIT ?

Sie scheinen die Tabellen bereits fertig, und „Business Rules“ klingt wie „Business-Leute sie Excel schreiben“ zu haben.

FIT ist ein System für Tests basierend auf Tabellen mit Input-> erwarteten Ausgangszuordnungen und eine Open-Source-Java-Bibliothek Überprüfung für diese Tests laufen zur Verfügung.

Answer 3

Wir haben versucht, FIT und entschied mit Concordion zu gehen. Die wichtigsten Vorteile dieser Bibliothek sind:

• kann die Tests neben der Code-Basis geprüft werden in (in eine Subversion-Repository, zum Beispiel)
• sie durch eine Standard JUnit runner ausgeführt werden

Answer 4

Ich schrieb etwas sehr ähnlich JUnit verwenden. Ich hatte eine große Anzahl von Testfällen (30 Seiten) in einer XML-Datei. Anstatt zu versuchen, verschiedene Tests zu generieren, habe ich das alles in einem einzigen Test, der ganz gut funktioniert.

Mein Test sah etwa so aus:

void setup() { 
  cases = read in the xml file
}

void test_fn_works() {
  for case in cases {
    assert(case.expected_result, fn(case.inputs), 
        'Case ' + case.inputs + ' should yield ' + case.expected_result);

  }
}

Mit Rubin, ich habe genau das, was Sie saying-- Erzeugungstests im laufenden Betrieb sind. obwohl dies zu tun in Java, ist, komplex, und ich glaube nicht, es ist es wert, da es eine andere, durchaus sinnvoller Ansatz.

Hope, das hilft.