Assertion.ru

Conformance-Test Entwicklung beinhaltet die Ermittlung Behauptungen in einer Spezifikation, schriftlich Conformance-Tests, dass die identifizierten Behauptungen zu überprüfen und die Verknüpfung der Test zu der Behauptung, dass es Tests.
Fangen wir von den folgenden Punkten:
- Behauptung ist markiert
- Tatsächliche Behauptung ist schwierig, in der spec (view derzeit sind es nur kleine Behauptung gif's am Ende jeder Behauptung)
- Abschluss der Behauptungen sind nur durch das Lesen der HTML direkt oder Blick auf die einzelnen Tests angesehen
- Beginn der Behauptungen sind schwer in den HTML-Code zu sehen
- Bereitstellung eines visuellen Weg, um die Behauptung Blick leicht ist das Problem, das wir zu lösen versuchen.

Der wichtigste Punkt ist die Farbe der Behauptungen (Spezifikation Text selbst) mit HTML-Tags. Die Untersuchung wurde vorgenommen, welche HTML-Tags zu verwenden. Div, span, Tisch und font-Tags wurden betrachtet. Die beste Lösung ist das font-Tag. So wird der Text mit font-Tags umgeben. Die Klasse Attribut des font-Tag entspricht dem Typ der Behauptung. Fe, wenn die neue asserion ist es mit rot gefärbt ist, um anzuzeigen, dass Prüfungen geschrieben werden müssen, sind alte Behauptungen mit grüner Farbe, um anzuzeigen, dass Tests gibt es bereits. Es sollte ein Programm (Script oder Java-Programm) werden bis Scan-Spezifikation markiert und automatisch die Tags für die Einfärbung benötigt. Die Hintergrundfarbe des Textes wird durch das title-Attribut Farbe der Behauptung bestimmt werden. Diese Methode wurde umgesetzt und funktioniert gut. Für Zwecke Usability, sollte es einen Mechanismus zu verbergen Färbung werden, zB ein JavaScript.

Ein Nachteil dieser Lösung ist, dass die Farbe statisch ist, da sie auf das title-Attribut basiert. Eine zweite Lösung wäre, dass das Tool wäre für ein Bestehen einer Prüfung (auf die Behauptung, ID oder den Link in der Behauptung aus, überprüfen). Wenn ein Test existiert, würden wir etwas tun, um die Farbe dieser Behauptung gesetzt. Man könnte so einfach sein wie Festlegung eines title-Attribut. Ein Nachteil dieser Lösung wäre, dass die Behauptung Färbung wäre immer noch statisch, sondern basierend auf, wenn der Benutzer die Skripts ausführen.

Eine Variation der gegebenen Lösung ist, dass wir dynamisch erzeugen die Coverage-Daten, wenn das spec in einem Browser angezeigt wird. Wir möchten feststellen, ob ein Test in der Test-Verzeichnis für eine bestimmte Aussage und Farbe entsprechend der Behauptung existiert. Dies könnte durch ein JavaScript getan werden / VBScript mit Objekten, die Zugriff auf Datei-System zu ermöglichen. Diese Methode wäre, dynamischen und sollte immer auf dem neuesten Stand Behauptung Abdeckung.

Hier sind einige Beispiele aus JLS3 Kapiteln "Conversions und Promotions" und "Schnittstellen":

Assertions conv063, conv047, conv065, conv48, conv66 conv049 und sind von den vorherigen Version von spec, waren sie nicht verändert und Tests Update ist nicht erforderlich - Farbe ist Aquamarin (neurtal grün). Conv155 conv156 und neu sind, sollten neue Tests entwickelt werden, Behauptungen sind in grellen rot gefärbt. Conv064 geändert wurde, Test-Update notwendig - Farbe orange. Annot019 ist ein neues, Tests existieren, aber sie sind notwendig, um geändert werden - Lachs Farbe. Annot020 ist neu, aber кудумфте Tests bestehen - Farbe hellgrün.

Der Hauptvorteil des spec Färbung ist, dass die spec visualisiert wird. User können Sie die gesamte Aussage und ihre Titel. Man kann, indem man die spec, wo gibt es Bereiche mit geringer Reichweite, bei denen einige oder viele Tests hinzugefügt oder geändert werden sollte erzählen. Es besteht grundsätzlich die Möglichkeit zu sehen, wie gut ein spec up ist und markiert, wie gut es ist, getestet.

• alt:
  nicht verändert Text, tun Tests benötigen keine Veränderungen;
• oldToBeChanged:
  Text verändert, Tests machen müssen geändert werden;
• neu:
  total neuen Text, neue Prüfungen erforderlich sind;
• newWritten:
  neuen Text, Tests, sondern bereits vorhanden (weil die Entwicklung von Tests Prozess begann, sobald der Entwurf der Spezifikation zur Verfügung stand);
• newWrittenToBeChanged:
  neuen Text gibt es Tests, Entwurf spec verändert, so dass die Tests müssen geändert werden oder die vorhandenen Tests sind nicht genug.

Tipp 2: Algorithmus sollte überprüfen, ob die zweite Anker sollte nach dem ersten Teil und nicht allzu weit davon entfernt positioniert werden.

1. Schauen Sie sich den Text vor und nach tag in alten spec. Finden Sie es in den neuen spec. Wenn einer von ihnen wurde nicht verändert - die Antwort ist gefunden. Die Länge sollte in der Regel 1-2 sentances werden, mindestens 60 Zeichen lang sein. Wenn keine oder mehrere sentances gefunden - diesen Schritt überspringen.
2. Versuchen Sie, die gleiche wie zu tun in (1), sondern entfernen Sie alle HTML-Tags aus dem Text, der in der Nähe von dem Tag umgibt. Wenn keiner gefunden - diesen Schritt überspringen.
3. Probieren Sie den Algorithmus zu erlassen, die zu ähnlichen Text in der neuen Spezifikation zu finden versucht.
   ein. Verwenden Sie die Schritte (1) und (2), aber desrease die Länge der Benutzer Text in einer Schleife, bis die Sentance gefunden wird oder die Länge zu kurz ist. Die praktische Arbeit hat gezeigt, dass diese Zahl sollte nicht kleiner als 20 sein.
   b. Wenn die Schritte (1) und (2), oder (3a) fand mehrere sentances Erhöhung der Länge des Textes bis zur Volltextsuche ist in der neuen Spezifikation entsprechen, oder die obere Grenze (zB 140 Zeichen) erreicht ist gefunden. Verwenden Sie Hinweise zu den am besten passenden Text zu finden.