8 Stimmen

Verwendung von Zufälligkeiten und/oder Iterationen in Unit-Tests?

Bei Unit-Tests habe ich mir angewöhnt, Methoden zu testen, die einige reguläre Werte, einige Werte, die gegen den Methodenvertrag verstoßen, und alle Grenzfälle, die mir einfallen, anwenden.

Aber ist es eine schlechte Praxis, wenn

  • Wenn Sie einen Test mit zufälligen Werten durchführen, ist dies ein Wert innerhalb eines Bereichs, von dem Sie glauben, dass er keine Probleme verursachen sollte, so dass jedes Mal, wenn der Test läuft, ein anderer Wert eingegeben wird? Als eine Art ausführlicher Test für regelmäßige Werte?
  • Prüfung ganzer Bereiche durch Iteration ?

Ich habe das Gefühl, dass diese beiden Ansätze nicht gut sind. Bei Reichweitentests kann ich mir vorstellen, dass es einfach nicht praktikabel ist, das zu tun, weil es so viel Zeit in Anspruch nimmt, aber bei Zufälligkeit?

UPDATE :

Ich wende diese Technik selbst nicht an, ich habe mich nur darüber gewundert. Ich weiß jetzt, dass der Zufall ein gutes Werkzeug sein kann, wenn man ihn bei Bedarf reproduzierbar machen kann.
Die interessanteste Antwort war der "Fuzzing"-Tipp von Lieven:

http://en.wikipedia.org/wiki/Fuzz_testing

tx

1voto

Garry Shutler Punkte 31414

Solange es Ihnen auf irgendeine Weise mitteilt, bei welchem Zufallswert es fehlgeschlagen ist, halte ich es nicht für so schlimm. Allerdings sind Sie dann fast auf Glück angewiesen, um ein Problem in Ihrer Anwendung zu finden.

Die Prüfung des gesamten Spektrums stellt sicher, dass Sie alle Möglichkeiten abdecken, aber es scheint übertrieben, wenn Sie die Ränder abdecken und, wie ich annehme, einige akzeptierte Werte im mittleren Bereich haben.

1voto

philant Punkte 32877

Das Ziel von Unit-Tests ist es, Vertrauen in Ihren Code zu gewinnen. Wenn Sie also fühlen dass die Verwendung von Zufallswerten dazu beitragen könnte, mehr Fehler zu finden, müssen Sie natürlich mehr Tests durchführen, um das Vertrauensniveau zu erhöhen.

In dieser Situation könnten Sie sich auf iterationsbasierte Tests verlassen, um diese Probleme zu identifizieren. Ich würde empfehlen, neue spezifische Tests für die Fälle zu erstellen, die mit den Schleifentests entdeckt wurden, und die iterationsbasierten Tests dann zu entfernen, damit sie Ihre Tests nicht verlangsamen.

1voto

DanM Punkte 2201

Ich habe die Zufälligkeit zur Fehlersuche bei einem Feldproblem mit einem Zustandsautomaten verwendet, dem eine Ressource entweicht. Wir haben den Code inspiziert, die Unit-Tests durchgeführt und konnten das Leck nicht reproduzieren.

Wir haben zufällige Ereignisse aus dem gesamten möglichen Ereignisraum in die Testumgebung der Zustandsmaschine eingespeist. Wir haben uns die Invarianten nach jedem Ereignis angesehen und angehalten, wenn sie verletzt wurden.

Die Zufallsereignisse legten schließlich eine Abfolge von Ereignissen offen, die zu einem Leck führten. Der Zustandsautomat verlor eine Ressource, als ein zweiter Fehler auftrat, während er sich von einem ersten Fehler erholte.

Anschließend konnten wir das Leck in der Praxis reproduzieren.

Der Zufall hat also ein Problem gefunden, das sonst nur schwer zu finden war. Ein wenig rohe Gewalt, aber dem Computer machte es nichts aus, am Wochenende zu arbeiten.

0voto

Makis Punkte 11700

Ich würde nicht für völlig zufällige Werte plädieren, da sie Ihnen ein falsches Gefühl der Sicherheit vermitteln. Wenn Sie nicht den gesamten Bereich durchgehen können (was oft der Fall ist), ist es viel effizienter, eine Teilmenge von Hand auszuwählen. Auf diese Weise müssen Sie auch an mögliche "ungerade" Werte denken, d. h. Werte, bei denen der Code anders läuft (und die nicht in der Nähe von Kanten liegen).

Sie könnten einen Zufallsgenerator verwenden, um die Testwerte zu erzeugen, prüfen, ob sie eine gute Stichprobe darstellen und sie dann verwenden. Dies ist vor allem dann eine gute Idee, wenn die Auswahl per Hand zu zeitaufwändig wäre.

Ich habe zufällige Testwerte verwendet, als ich einen Semaphor-Treiber für einen Hw-Block von zwei verschiedenen Chips schrieb. In diesem Fall konnte ich nicht herausfinden, wie ich sinnvolle Werte für die Timings auswählen sollte, also habe ich randomisiert, wie oft die Chips (unabhängig voneinander) versuchen würden, auf den Block zuzugreifen. Im Nachhinein wäre es immer noch besser gewesen, sie von Hand zu wählen, denn die Testumgebung so zu gestalten, dass sich die beiden Chips nicht aneinander ausrichten, war nicht so einfach, wie ich dachte. Dies war eigentlich ein sehr gutes Beispiel dafür, dass Zufallswerte keine Zufallsstichprobe ergeben.

Das Problem wurde durch die Tatsache verursacht, dass immer dann, wenn der andere Chip den Block reserviert hatte, der andere wartete und getreu einem Semaphor den Zugriff erhielt, gleich nachdem der andere ihn freigegeben hatte. Als ich aufzeichnete, wie lange die Chips auf den Zugriff warten mussten, waren die Werte in der Tat weit vom Zufall entfernt. Am schlimmsten war es, wenn ich den gleichen Wertebereich für beide Zufallswerte hatte. Es wurde etwas besser, nachdem ich sie so verändert hatte, dass sie unterschiedliche Bereiche hatten, aber es war immer noch nicht sehr zufällig. Erst nachdem ich die Wartezeiten zwischen den Zugriffen randomisiert hatte, bekam ich so etwas wie einen Zufallstest und wie lange der Block reserviert war und wählte die vier Sätze sorgfältig aus.

Am Ende habe ich wahrscheinlich mehr Zeit damit verbracht, den Code zu schreiben, um "zufällige" Werte zu verwenden, als ich gebraucht hätte, um überhaupt sinnvolle Werte von Hand auszuwählen.

0voto

Carl Manaster Punkte 38966

Siehe David Saffs Arbeit über Theoriegestütztes Testen .

Im Allgemeinen würde ich Zufälligkeiten in Unit-Tests vermeiden, aber die Theorie ist faszinierend.

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X