Assertion.ru

Wie schon vor dem Endprodukt erwähnt wird die Anzahl der Tests. Es besteht ein Zusammenhang zwischen den Prüfungen und der Spezifikation. Die Behauptung-gesteuerter Prozess vermittelt eine Vorstellung von dem, was jede Gruppe von Tests tatsächlich Kontrollen in der Spezifikation. Mit Hilfe dieser Beziehung kann der Entwickler die Berichterstattung zu berechnen, um die Liste aller Behauptungen, auf denen die Tests wurden nicht geschrieben, usw.

Assertion ist eine Aussage von einer Spezifikation, die getestet werden kann. Und der erste Schritt besteht darin, alle Aussagen in der Spezifikation zu identifizieren. Danach kann der Entwickler schreiben Tests.

Beispiel für die Behauptungen aus der Java Language Specification:

Es könnte viele Aussagen, die nicht überprüfbar sind oder beinhalten Unsicherheiten. Manchmal werden solche Aussagen gehören Wörter wie "möglich" oder "vielleicht". Es ist nicht wahr, dass, wenn ein Satz ist ein Wort "kann" ist nicht überprüfbar ist, aber in der Regel ist es so.

Beispiele für nicht überprüfbare Aussagen:

Es gibt viele Diskussionen und Streitigkeiten über die Behauptungen. Einige sagen, dass die Beispiele nicht als Aussagen behandelt werden. Andere sagen, dass jede Anweisung ein Behauptungen ist und es gibt zwei Arten von ihnen: überprüfbare und nicht überprüfbar. Meine persönliche Meinung ist, dass eine Behauptung ist sicherlich etwas überprüfbar. Und in den meisten Fällen Beispiele Behauptungen, nur weil der Test geschrieben werden können Überprüfung der speziellen Beispiel.

Der Prozess der Identifizierung Behauptungen in der Spezifikation wird als Markup. Es gibt viele Ansätze. Aber in jedem Fall muss der Benutzer in der Lage, Informationen darüber, ob die Aussage ist eine Behauptung, und irgendwie unterscheiden, eine Behauptung von anderen zu gelangen. Es könnte ein separates Repository mit Zuordnung von Aussagen und ihre id's Aussagen. Ich mag die Idee der Integration der Markup in der Spezifikation. Dieser Ansatz wurde für den Bereich der Sprache Java SE Test-Suite ausgewählt. Die JLS wurde in FrameMaker geschrieben. Mit dem Export Mechanismen der PDF-und HTML-Versionen erstellt wurden. Die HTML-Version wurde bei der Erstellung der Test-Suite verwendet.

In JLS und JLS 2 einige spezielle Anker identifiziert den Anfang und das Ende einer Behauptung. Weitere Informationen bei der assertionID und kurze Zusammenfassung der Erklärung. Das Ende Anker war ein Bild und einen Link auf die Probe. Die HTML-Ansicht und Code-Ansicht auf den entsprechenden Abbildungen gezeigt. Die Behauptung, id sind arr033, arr034, arr020, etc.

Die allgemeine Idee, können wie folgt beschrieben werden:

<a name=assertionID> <! - shord Beschreibung als HTML-Kommentar ->
Assertion hier
<img src="pics/assert.gif"> <a href="path zu test"> Test-ID, die ist die gleiche wie Behauptung ID </ a>

Wenn getrennte Erklärungen in verschiedenen Teilen der Spezifikation werden von einem Test der erste Tag geprüft wird so etwas wie arr033_0, arr033_1, arr033_2.

Diese Art der Architektur wurde für JLS und JLS-2 verwendet. Es war leicht für JLS3 geändert, aber die Grundidee wurde beibehalten. Ich kenne einige Beispiele von Ansätzen mit nicht-statische Behauptung IDs in einem separaten Repository, wo-ID ist eine Hash-Wert gehalten, berechnet auf der Grundlage des Inhalts. Aus verschiedenen Gründen ist es zeigte sich nicht als eine sehr gute Lösung. Es gibt immer einen harten Prozess der Migration auf die neue Version der Spezifikation. Aber meiner Meinung nach ist es viel einfacher mit der statischen ID eingebettet in die Spezifikation.