it-swarm.com.de

Helfermethoden von Testklassen trennen?

Beim Testen kann manchmal eine Hilfsmethode für wiederholte Aufgaben nützlich sein, z. im Testaufbau.

Konkretes Beispiel: Wir haben bestimmte Tests gegen unsere Rest-Schnittstelle mit Spring's RestTemplate. Zur Vereinfachung werden die Anforderungen mit Hilfe einer Hilfsmethode gesendet (nennen wir sie vorerst Methode A()), die die Objekte aus der Antwort zurückgibt.

Diese Hilfsmethode A() scheint die Testklasse zu verschmutzen, da es sich um eine Methode handelt, die eigentlich kein Test selbst ist. Das Vorhandensein mehrerer Hilfsmethoden in einer Testklasse wirkt sich negativ auf die Übersicht aus.

Ist es akzeptabel, eine zweite Klasse neben der Testklasse zu erstellen, die alle Hilfsmethoden enthält? Was wären die Schwierigkeiten, wenn dies der Fall wäre? Oder gibt es andere Möglichkeiten, um einen guten Überblick über die Testklasse zu behalten?

  • MyTestClass -> enthält nur Methoden, die ein tatsächlicher Test sind
  • MyTestClassUtil -> enthält alle Hilfsmethoden, die von MyTestClass verwendet werden
9
Herr Derb

Ist es akzeptabel, eine zweite Klasse neben der Testklasse zu erstellen, die alle Hilfsmethoden enthält?

Nicht mit all Hilfsmethoden, sondern mit Hilfsmethoden, die in mehr als einer Testklasse verwendet werden.

Entwerfen Sie Ihre Tests genauso wie Sie Business Classes implementieren!

Refactor-Code wird innerhalb einer Klasse in eine lokale Methode dupliziert. Wenn die Methode in verschiedenen Testklassen verwendet wird, verschieben Sie sie in eine andere Testhelferklasse, die von verschiedenen Tests verwendet wird.

Meine OrderTests Klasse hat also eine lokale Methode assertEqual(String message, IOrder expected, IOrder actual) und mein Helfer TestDataFactory hat eine statische Methode createTestOrder(), die in OrderTests verwendet wird , PriceCalculationTests, PaymentTests, DeliveryTests.

Ein Test kann eine oder mehrere der werkseitigen Standardmethoden verwenden und diese nach Bedarf ändern. Beispiel:

DeliveryTests.executeOrderWithNoDeliveryAdressShouldThrow() {
    // a valid standard order with one article, user, deliveryadress, ...
    Order sut = TestDataFactory.createTestOrder(); 
    sut.setDeliveryAdress(null); // implements "WithNoDeliveryAdress"

    try {
        sut.execute(); // this should throw
        Assert.fail(); // this should never be reached because of exception.
    } catch(OrderNotCompleteException) {
    }
}
10
k3b

Laut Michael C. Feathers in Effektiv mit Legacy-Code arbeiten Sie können eine so genannte Objektnaht erstellen. Eine Klasse, die die Schnittstelle implementiert, die Sie testen oder von der Klasse erben, die Sie testen. In diesem Fall kontaminieren Sie Ihren Originalcode nicht mit Unit-Tests.

2
A.Rashad