Codegenerierung verwenden, um Testdaten zu generieren

Ich stoße häufig auf Situationen, in denen ich den Inhalt eines großen Objektdiagramms (Laufzeit oder Debugging) in einer Reihe von Anweisungen speichern möchte, die dieses Objektdiagramm neu erstellen. Dies kann dann als Testdaten in Unit-Testfällen verwendet werden.Codegenerierung verwenden, um Testdaten zu generieren

genommen, daß Blätter des Objektgraphen sind Standardtypen (String, BigDecimal, Date, usw.) und die Zweige folgen der bean convention (Getter, Setter, leeren Konstruktor), sollte es möglich sein, zu erzeugen, diese Art von Datei (zB TestData.java):

public static Car createCar() { 

    Wheel wheel1 = new Wheel(); 
    wheel1.setTypePressure(2.1f); 
    Wheel wheel2 = new Wheel(); 
    wheel2.setTypePressure(2.3f); 
    Wheel wheel3 = new Wheel(); 
    wheel3.setTypePressure(2.0f); 
    Wheel wheel4 = new Wheel(); 
    wheel4.setTypePressure(2.8f); 
    List<Wheel> wheels = new ArrayList<>(Arrays.asList(wheel1, wheel2, wheel3, wheel4)); 

    Brake brake = new Brake(); 
    brake.setBrakeType(BrakeType.PLAIN); 

    Car car = new Car(); 
    car.setBrake(brake); 
    car.setWheels(wheels); 
    car.setColor("blue"); 

    return car; 
}

Es wäre wirklich toll, das irgendwie direkt in eine Debug-Sitzung zu stopfen, aber ein paar Drop-in-Anweisungen als Folge des „Java-Objekt der Diagrammerstellung Code schreiben mit Inhalt "Ausgabe an System.out würde auch funktionieren.

Also, wie kann ich das auf die effizienteste Weise realisieren?

Quelle

2017-02-08 sjaak

Schöne Idee, aber (wahrscheinlich rechthaberisch) nicht die beste Lösung.

Ja, diese Daten könnten in ein Java-Programm umgewandelt werden; was dann gespeichert werden muss, kompiliert, ...

Dann entstehen Fragen wie: wollen Sie Quellcode herum oder kompilierten Code halten; Was ist mit Versionierung (von Daten oder der zugrunde liegenden JRE)?

Lange Rede kurzer Sinn: Java-Code ist kein sehr praktisches Format zur Darstellung Daten. Also: Anstatt Ihre Daten in Java-Code umzuwandeln, wandeln Sie sie in eine JSON-Darstellung um.

Der Punkt ist: Wenn Ihre Klassen wirklich "Bohne Stil" folgen; und sie haben bereits getters/setters/default constructors - dann beliebig anständige JSON Parser-Bibliothek sollte "out of the box" funktionieren. Du wirfst dein Auto-Objekt darauf; und raus kommt netter Standard JSON. Dann schreibst du ein kleines Hilfswerkzeug, das solche Dateien liest und sie wieder in Autoobjekte umwandelt. Erledigt.

Das ist der Weg zu gehen (und dieser Rat kommt von jemandem, der an einem System arbeitete, wo der Architekt genau das verlangte, wonach Sie verlangten; und wir haben viel Zeit und Mühe investiert, um dorthin zu gelangen ... aber das war vor mehr als 10 Jahren, und das macht man 2017 einfach nicht mehr).

Angesichts Ihrer letzten Kommentar (wie Sie hauptsächlich in Unit Testcode interessiert sind); Ich würde vorschlagen, mit dem Erbauer Muster hier zu suchen.

Damit Ihr Code würde einkochen zu

new CarBuilder().wheel(new WheelBuilder(). ...

Das Schöne daran, dass: es gibt verschiedene Möglichkeiten, um solche Builder für Sie zu erzeugen; Zum Beispiel hat das Projekt Lombok eine @Builder Annotation!

In jedem Fall ist der Markt für die Generierung von Erstellern automatisch schön rich!

Quelle

2017-02-08 08:10:21 GhostCat

Ich stimme zu. Ich schlage auch vor, ein einfaches Beispiel von, sagen wir, GSON bei der Arbeit fallen zu lassen. Es ist unglaublich, was man mit einem One-Liner machen kann, und es wird wahrscheinlich OP mehr als nur sagen, dass es einfach ist. – tucuxi

Wenn es keine Out-of-the-Box-Lösung gibt, werde ich JSON versuchen. Meine einzige Sorge ist, dass Daten, die in einer separaten JSON-Datei von Ihrem (Junit) Test-Code aufbewahrt werden, nicht refactoring unterzogen werden. Ergo: Wenn sich mein Modell ändert (Attributnamen, Entitätsnamen), wird der Refactor automatisch die Java-Lösung angehen. Gib zu: Wenn sich die Struktur ändert, habe ich sowieso ein Problem. – sjaak

@tucuxi. Ich habe gerade an meinem kleinen Beispiel versucht. Es ist wirklich erstaunlich. – sjaak

Mir ist kein IDE-Plugin bekannt, das das tun würde, und ich konnte kein Googling finden.In Abwesenheit eines vorhandenen Plugins (für Ihre IDE) von jemand anderem geschrieben, die Antwort auf Ihre Frage:

Wie kann ich das auf die effizienteste Weise realisieren?

hängt davon ab, ob es sich um effizienter zu das Plugin entwickeln (selbst!) Oder einfach weiter mit den Testfälle mit der Hand zu schreiben.

Meine Vermutung ist, dass letztere effizienter sein wird.

Auch ich stimme mit @ GhostCat's. Wenn Ihre Testfälle "datenintensiv" sind, wäre es besser, ein textbasiertes serielles Format für die Testdaten zu wählen/zu implementieren und die Testdaten auf diese Weise auszudrücken. Meiner Erfahrung nach ist es einfacher, Testdaten zu lesen/zu modifizieren, die auf diese Weise ausgedrückt werden, als Testdaten, die als ein Bündel von Java-Aufrufen zum Konstruieren von Objektgraphen codiert sind. Es ist wichtig, dass Ihre Testfälle nicht "nur schreiben" sind.

Quelle

2017-02-08 08:13:22

Danke. Ich entschied mich für die obige Lösung. – sjaak

Ich würde versuchen, Ihren Graphen in einer lesbaren, aber dennoch lesbaren Form zu erhalten. XML ist möglicherweise die beste Wahl, da die Syntax dokumentenübergreifende Verweise erlaubt, aber jedes Format funktioniert - sogar eine benutzerdefinierte Syntax. Auf diese Weise können Sie Grafiken zur Laufzeit beibehalten und übertragen, während einfach zu modifizierende und replizierende Testgrafiken für Komponententests unterstützt werden.

Quelle

2017-02-08 19:28:48

Codegenerierung verwenden, um Testdaten zu generieren

Antwort

Verwandte Themen