(Einige) Geheimnisse von DoFixture enthüllt

Für automatisierte Akzeptanztests verwenden wir das Fitnesse-Framework. Fitnesse ist eine Wiki-Seite, die es Testern ermöglicht, ausführbare Tests als Wiki-Seiten zu schreiben. Wiki-Seiten bestehen aus Text als Kommentare und Tabellen als Tests. Um die Tabellen in den Anwendungscode zu integrieren, schreiben die Entwickler Fixtures. Fixtures sind eine sehr dünne Softwareschicht, die den Anwendungscode aufruft und im Wiki angezeigt werden kann. Das System ist sehr einfach zu bedienen. Fitnesse enthält eine Reihe nützlicher Fixtures, aber das bei weitem nützlichste Fixture stammt aus einer separaten Bibliothek (FitLibrary): Die DoFixture. Eine DoFixture stellt jede öffentliche Methode als eine Zeile in einer Tabelle dar. Jede ungerade Zelle in der Zeile ist ein Teil des Methodennamens und jede gerade Zelle ist ein Parameter. Dadurch ist die Tabelle leicht zu lesen. Die Zeile

ruft also die Methode trainLeavesStationAtToStation('123', 'Amsterdam', '12:00', 'Utrecht Centraal') auf. Wie Sie sehen, werden die Wörter in den ungeraden Zellen in Kamelschreibweise verkettet. Leider sind nicht alle Funktionen dieser Vorrichtung oder des Fitnesse-Frameworks gut dokumentiert und leicht zu finden. In diesem Blog werden eine Reihe von Funktionen aufgeführt, die die Effizienz der Verwendung von Fitnesse verbessern können. Die gezeigten Funktionen sind Fixture Loading, Parse Delegates und System under Test. Um die Nützlichkeit der letzten Funktion zu erhöhen, werden wir uns auch einige Verbesserungen ansehen. Dieser Blog basiert auf der gleichen Version von Fitnesse und fitlibrary wie das Buch "Fit for Developing Software".

FixtureLoading Wussten Sie, dass DoFixture automatisch in allen bekannten Fixture-Paketen nach einem Fixture sucht, wenn Sie eine neue Tabelle beginnen? Wenn Sie eine Seite haben, die mit einer (voll qualifizierten) Fixture-Klasse in einer Tabelle beginnt, wie

Jede nächste Tabelle, die mit einem (nicht qualifizierten) Fixturnamen beginnt, wird von diesem Fixture anstelle des ursprünglichen Fixtures ausgeführt. Daher wird die Tabelle

wird von der com.xebia.fitnesse.MeaningfulNameFixture ausgeführt. Beachten Sie, dass "sinnvoller Name" in MeaningfulNameFixture umgewandelt wird und im selben Paket gesucht wird, in dem auch das ursprüngliche Fixture gefunden wurde. ParseDelegate Wussten Sie, dass Sie ParseDelegates mit FitLibrary Fixtures wie DoFixture verwenden können? Ein ParseDelegate ist ein Objekt, das für die Umwandlung eines Strings in einen bestimmten (komplexen) Objekttyp und umgekehrt zuständig ist. Zu diesem Zweck benötigt das ParseDelegate nur eine Methode: Typ parse(String). Ein einfaches Beispiel, das BigInteger konvertiert, sehen Sie unten.

public class BigIntegerParseDelegate {
  public BigInteger parse(String Wert) {
  return new BigInteger(Wert);
  }
}

Wie Sie sehen können, ist der Code ziemlich einfach. Komplexere Konvertierungen können jedoch nützlich sein. Das ParseDelegate unten konvertiert LocalDate Objekte (JodaTime).

public class LocalDateConverter {
  public LocalDate parse(String date) {
  LocalDate Ergebnis;
  if (date.startsWith("+") || date.startsWith("-")) {
  int days = Integer.parseInt(date.substring(1));
  Periode Periode = Periode.Tage(Tage);
  Ergebnis = new LocalDate();
  if (date.startsWith("+")) {
  result = result.plus(period);
  } sonst {
  Ergebnis = Ergebnis.minus(Zeitraum);
  }
  } sonst {
  result = new LocalDate(date);
  }
  Ergebnis zurückgeben;
  }
}

Dieser Parse-Delegate ermöglicht das Addieren oder Subtrahieren einer bestimmten Anzahl von Tagen zum aktuellen Datum durch die Verwendung von Plus- oder Minuszeichen in der Zelle. ParseDelegates können über die Methode registerParseDelegate(Class, Object oder Class) zu einer statischen Map in der Klasse FitLibraryFixture (ein Elternteil von DoFixture) hinzugefügt werden. Der Delegat wird zum Parsen von Objekten verwendet, wenn ein Objekt des ersten Parametertyps als Parametertyp für eine Methode benötigt wird. SystemUnderTest Wussten Sie, dass DoFixture über einen 'SystemUnderTest' verfügt? Ein SystemUnderTest ist ein einfaches Java-Objekt, das als Delegat für das Fixture arbeitet. Immer wenn beim Parsen einer Tabelle eine Methode gefunden werden muss, sucht das Fixture nach der Methode in seiner eigenen Klasse und wenn keine gefunden wird, sucht es nach der Methode in der Klasse des SystemUnderTest. Die Methode wird dann auf dem SystemUnderTest-Objekt aufgerufen. Auf diese Weise kann Fitnesse direkt mit dem Anwendungscode arbeiten, anstatt die gesamte Funktionalität über Fixtures offenzulegen. Eine weitere großartige Funktion von DoFixture ist, dass, wenn die aufgerufene Methode eine Instanz einer komplexen (nicht primitiven) Klasse zurückgibt, das Ergebnis in eine neue DoFixture verpackt wird, so dass Fitnesse auch mit dem Ergebnis arbeiten kann. Nehmen wir an, wir haben eine Klasse Container, die eine Eigenschaft vom Typ Contained mit dem Namen 'contents' hat und dieser Typ hat eine Eigenschaft vom Typ String mit dem Namen 'value'. Die unten stehende Tabellenstruktur wird den Wert der Instanz von Contained abfragen.

Der Ausgangspunkt dieser Abfrage ist die Methid 'methodThatReturnsInstanceOfContainerType', die in einer Fixture-Klasse implementiert ist. Der zurückgegebene Wert ist eine DoFixture, die den zurückgegebenen Wert als SystemUnderTest enthält. Die zweite Zeile ruft die Methode 'getContents' für SystemUnderTest auf, die die Instanz Contained zurückgibt, die ebenfalls umhüllt ist. Die dritte Zeile überprüft die Eigenschaft value auf 'expected'. Diese Funktion eignet sich hervorragend für die Überprüfung von Werten in einer komplexen Struktur, die Sie in Ihrer Anwendung verwenden. Sie können sie auch verwenden, um Werte zu setzen. Das Schlüsselwort 'set' wird übrigens nicht zu den Eigenschaftsnamen hinzugefügt. Nachteil von SystemUnderTest Ein Nachteil der Funktion SystemUnderTest ist, dass es keine Möglichkeit gibt, die Kette der Domänenobjekte nach oben zu durchlaufen (oder besser gesagt, ich habe sie noch nicht gefunden. Das könnte ein weiteres Geheimnis sein, das es zu lüften gilt...). Um nach oben zu gelangen, sollten alle Domänenobjekte, die durchlaufen wurden, in einem Stack abgelegt werden und eine neue 'pop'-Methode sollte hinzugefügt werden, um auf dem Stack nach oben zu gelangen. Immer wenn ein DoFixture zurückgegeben wird, wird der aktuelle SystemUnderTest auf den Stack geschoben und der SystemUnderTest aus dem Fixture wird als neuer SystemUnderTest gespeichert. Eine Implementierung dieses Mechanismus finden Sie in diesem Anhang zu diesem Blog. Es gibt auch einen kleinen Unittest, der zeigt, wie das Fixture verwendet werden kann.Zusätzlich zum Aufwärtsbewegen in der Domänenobjektkette ermöglicht diese Implementierung auch das Durchlaufen von Listen, und zwar über dasselbe System wie oben beschrieben. Indem Sie die Liste als SystemUnderTest festlegen, wird die 'get'-Methode der Liste offengelegt, was die Überprüfung der Werte in der Liste ermöglicht. Durch das Popping der Elemente in der Liste und später der Liste selbst können Sie sich in der Kette wieder nach oben bewegen. Diese Implementierung ist zwar nützlich, wenn Sie komplexe Anwendungsdaten testen, aber sie verstößt auch gegen das Fit-Prinzip, um die Testseiten für Menschen lesbar zu machen. Das Fixture führt die 'technischen' Wörter wie 'pop' und 'get | index' ein und kann zu potenziell sehr großen Testtabellen führen. Ich empfehle Ihnen, sie mit Vorsicht zu verwenden.