FitNesse Refactorings

Ich möchte Ihnen einige FitNesse Refactorings vorstellen, die ich für sehr nützlich halte. Diese Refactorings werden Ihnen helfen, Ihre Tests auf die sich ständig ändernden Anforderungen vorzubereiten. Dies ist das Szenario: Ich muss sicherstellen, dass, wenn der Benutzer eine Eigenschaft in einer Datei ändert, diese auch in der Datenbank geändert wird. Sie könnten für jede Eigenschaft Methoden wie property[PropertyName]IsChangedInto erstellen. Mit dem Schlüsselwort check in FitNesse können Sie feststellen, ob der neue Wert mit dem erwarteten Wert übereinstimmt oder nicht (Es gibt noch weitere Tabellenzeilen vor und nach dieser, aber ich habe sie aus Gründen der Lesbarkeit weggelassen): TestSeite |check|property phone|is changed into|020 6666666| Dies führt natürlich zu vielen Methoden in Ihrer Fixture, wenn Sie viele Eigenschaften zu prüfen haben. IntroduceParameter Sie können dieses Problem lösen, indem Sie die Eigenschaft phone zu einem Parameter machen, so dass der Fixture-Code wie folgt aussieht: |check property|phone|is changed into|020 6666666| Jetzt brauchen wir nur noch ein Mapping, das das Telefon einem Feld in unserem Code zuordnet, das überprüft werden muss. Der Nachteil dabei ist, dass, wenn Sie nicht aufpassen, Ihre Mappings an verschiedenen Stellen in verschiedenen Fixtures landen und wenn Sie Ihren Java-Code refaktorisieren, müssen Sie auch die Mappings refaktorisieren. Aber wie ein großer Holländer immer sagt: "Elk voordeel heb zijn nadeel" (alles hat seine Schattenseiten). Jetzt habe ich mich dafür entschieden, die Mappings in die FitNesse-Seite zu packen (Sie könnten auch eine Mapping-Klasse definieren, die alle Mappings enthält). TestSeite |map|phone|to|contactDetails.phoneNumber| |check|property|phone|is changed into|020 6666666| Ich denke, der Vorteil der FitNesse-Seite gegenüber dem Fixture-Code liegt darin, dass es lesbarer und klarer ist, was wozu zugeordnet wird. Auch wenn der Kunde sich nicht wirklich dafür interessiert, ist es für den Programmierer sicherlich lesbarer, und ich denke, Tests sind sowohl für den Kunden als auch für den Programmierer wichtig. Wenn die Zuordnung zu umfangreich wird, können Sie eine eigene Seite dafür erstellen und sie in die TestPage einbinden. Wie das geht, sehen Sie in ExtractPage. Wenn wir nun die Zuordnung erstellt haben, ist die Implementierung der Methode propertyChangedInto ziemlich einfach, vor allem, wenn Sie etwas wie PropertyUtils von common-beanutils verwenden.

public String propertyChangedInto(String propertyName) {
  return PropertyUtils.getNestedProperty(instanceFromDatabase, mapping.get(propertyName)).toString();
}

ExtractPage und ExtractVariable Wenn Sie mehr Eigenschaften überprüfen möchten, könnten Sie natürlich die FitNesse-Tabelle kopieren und das Telefon in ein anderes Feld ändern und die contactDetails.phoneNumber entsprechend ändern. Aber das führt zu vielen Wiederholungen.Die Lösung, die ich gefunden habe, besteht darin, eine FitNesse-Seite für die Tabelle zu extrahieren und in Variablen zu extrahieren. Nach der Umstrukturierung sieht die extrahierte FitNesse-Seite, nennen wir sie PageForTest, wie folgt aus: PageForTest |map|${fieldName}|to|${mappedFieldName}| |check |property|${fieldName}|is changed into|${newValue}| Und die resultierende TestSeite würde dann so aussehen: TestSeite !define fieldName {phone} !define mappedFieldName {contactDetails.phoneNumber} !define newValue {+31 020 666666} !include TableForTest Und wenn Sie zum Beispiel auch die Faxnummer testen müssen: TestSeite ----Test for phone----- !define fieldName {phone} !define mappedFieldName {contactDetails.phoneNumber} !define newValue {+31 020 666666} !include TableForTest ----Test for fax----- !define fieldName {fax} !define mappedFieldName {contactDetails.faxNumber} !define newValue {+31 020 777777} !include TableForTest Durch die Verwendung von Refactorings wie IntroduceParameter, ExtractPage und ExtractVariable können Sie robuste FitNesse-Tests erstellen. Auf diese Weise sind Ihre Tests besser auf kommende Änderungen der Anforderungen vorbereitet (und die werden kommen). Lars