Freigeben über

Testgenerierung

Bei herkömmlichen Komponententests besteht ein Test aus mehreren Dingen:

Es folgt eine Beispielteststruktur:

[Test]
void MyTest() {
    // data
    ArrayList a = new ArrayList();

    // method sequence
    a.Add(5);

    // assertions
    Assert.IsTrue(a.Count==1);
    Assert.AreEqual(a[0], 5);
}

IntelliTest kann häufig automatisch relevante Argumentwerte für allgemeinere parametrisierte Komponententests ermitteln, die die Abfolge von Methodenaufrufen und Assertionen bereitstellen.

Testgeneratoren

IntelliTest generiert Testfälle, indem eine Abfolge von Methoden der auszuführenden Implementierung ausgewählt und dann Eingaben für die Methoden generiert werden, während Assertionen über die abgeleiteten Daten überprüft werden.

Ein parametrisierter Komponententest gibt direkt eine Abfolge von Methodenaufrufen im Textkörper an.

Wenn IntelliTest Objekte erstellen muss, werden Aufrufe von Konstruktoren und Factorymethoden bei Bedarf automatisch der Sequenz hinzugefügt.

Parametrisierte Komponententests

Parametrisierte Komponententests (PUTs) sind Tests, die Parameter annehmen. Im Gegensatz zu herkömmlichen Komponententests, die in der Regel geschlossene Methoden sind, nehmen PUTs eine Reihe von Parametern. Ist es einfach? Ja – von dort aus versucht IntelliTest , den (minimalen) Satz von Eingaben zu generieren , die den Code vollständig abdecken , der aus dem Test erreichbar ist.

PUTs werden mithilfe des benutzerdefinierten PexMethod-Attributs auf ähnliche Weise wie MSTest (oder NUnit, xUnit) definiert. PUTs sind Instanzmethoden, die logisch in Klassen gruppiert sind, die mit PexClass markiert sind. Das folgende Beispiel zeigt einen einfachen PUT, der in der MyPexTest-Klasse gespeichert ist:

[PexMethod]
void ReplaceFirstChar(string target, char c) {

    string result = StringHelper.ReplaceFirstChar(target, c);

    Assert.AreEqual(result[0], c);
}

Dabei ist ReplaceFirstChar eine Methode, die das erste Zeichen einer Zeichenfolge ersetzt:

class StringHelper {
    static string ReplaceFirstChar(string target, char c) {
        if (target == null) throw new ArgumentNullException();
        if (target.Length == 0) throw new ArgumentOutOfRangeException();
        return c + target.Substring(1);
    }
}

Aus diesem Test kann IntelliTest automatisch Eingaben für einen PUT generieren, der viele Ausführungspfade des getesteten Codes abdeckt. Jede Eingabe, die einen anderen Ausführungspfad abdeckt, wird als Komponententest "serialisiert":

[TestMethod, ExpectedException(typeof(ArgumentNullException))]
void ReplaceFirstChar0() {
    this.ReplaceFirstChar(null, 0);
}
...
[TestMethod]
void ReplaceFirstChar10() {
    this.ReplaceFirstChar("a", 'c');
}

Generische parametrisierte Komponententests

Parametrisierte Komponententests können generische Methoden sein. In diesem Fall muss der Benutzer die Typen angeben, die zum Instanziieren der Methode mithilfe von PexGenericArguments verwendet werden.

[PexClass]
public partial class ListTest {
    [PexMethod]
    [PexGenericArguments(typeof(int))]
    [PexGenericArguments(typeof(object))]
    public void AddItem<T>(List<T> list, T value)
    { ... }
}

Zulassen von Ausnahmen

IntelliTest bietet zahlreiche Überprüfungsattribute, um Ausnahmen in erwartete Ausnahmen und unerwartete Ausnahmen zu triagen.

Erwartete Ausnahmen generieren negative Testfälle mit der entsprechenden Anmerkung wie "ExpectedException(typeof(xxx)"), während unerwartete Ausnahmen fehlerhafte Testfälle generieren.

[PexMethod, PexAllowedException(typeof(ArgumentNullException))]
void SomeTest() {...}

Die Validatoren sind:

Testen interner Typen

IntelliTest kann interne Typen "testen", solange sie angezeigt werden. Damit IntelliTest die Typen sehen kann, wird das folgende Attribut ihrem Produkt- oder Testprojekt durch die Visual Studio IntelliTest-Assistenten hinzugefügt:

[assembly: InternalsVisibleTo("Microsoft.Pex, PublicKey=002400000480000094000000060200000024000052534131000400000100010007d1fa57c4aed9f0a32e84aa0faefd0de9e8fd6aec8f87fb03766c834c99921eb23be79ad9d5dcc1dd9ad236132102900b723cf980957fc4e177108fc607774f29e8320e92ea05ece4e821c0a5efe8f1645c4c0c93c1ab99285d622caa652c1dfad63d745d6f2de5f17e5eaf0fc4963d261c8a12436518206dc093344d5ad293")]

Annahmen und Behauptungen

Benutzer können Annahmen und Assertionen verwenden, um Voraussetzungen (Annahmen) und Postconditionen (Assertionen ) über ihre Tests auszudrücken. Wenn IntelliTest eine Reihe von Parameterwerten generiert und den Code "untersucht", kann es eine Annahme des Tests verletzen. In diesem Fall wird kein Test für diesen Pfad generiert und er wird stillschweigend ignoriert.

Assertionen sind ein bekanntes Konzept in regulären Komponententestframeworks, daher versteht IntelliTest bereits die integrierten Assert-Klassen , die von jedem unterstützten Testframework bereitgestellt werden. Die meisten Frameworks bieten jedoch keine Assume-Klasse . In diesem Fall stellt IntelliTest die PexAssume-Klasse bereit. Wenn Sie kein vorhandenes Testframework verwenden möchten, verfügt IntelliTest auch über die PexAssert-Klasse .

[PexMethod]
public void Test1(object o) {
    // precondition: o should not be null
    PexAssume.IsNotNull(o);

    ...
}

Insbesondere kann die Nicht-Null-Annahme als benutzerdefiniertes Attribut codiert werden:

[PexMethod]
public void Test2([PexAssumeNotNull] object o)
// precondition: o should not be null
{
   ...
}

Vorbedingung

Eine Voraussetzung für eine Methode drückt die Bedingungen aus, unter denen die Methode erfolgreich sein wird.

In der Regel wird die Voraussetzung erzwungen, indem die Parameter und der Objektzustand überprüft und eine ArgumentException oder InvalidOperationException ausgelöst wird, wenn sie verletzt wird.

In IntelliTest wird eine Voraussetzung für einen parametrisierten Komponententest mit PexAssume ausgedrückt.

Nachbedingung

Die Postcondition einer Methode drückt die Bedingungen aus, die während und nach der Ausführung der Methode gelten sollten, vorausgesetzt, deren Voraussetzungen waren anfänglich gültig.

In der Regel wird die Postcondition durch Aufrufe von Assert-Methoden erzwungen.

Mit IntelliTest wird eine Postcondition eines parametrisierten Komponententests mit PexAssert ausgedrückt.

Fehlgeschlagenen Tests

Wann schlägt ein generierter Testfall fehl?

  1. Wenn sie nicht innerhalb der konfigurierten Pfadgrenzen beendet wird, wird sie als Fehler betrachtet, es sei denn, die TestExcludePathBoundsExceeded-Option wird festgelegt.

  2. Wenn der Test eine PexAssumeFailedException auslöst, ist dies erfolgreich. Es wird jedoch in der Regel herausgefiltert, es sei denn TestEmissionFilter ist auf "Alle" festgelegt.

  3. Wenn der Test gegen eine Assertion verstößt, zum Beispiel durch das Auslösen einer Assertionsverletzungs-Ausnahme eines Komponententestframeworks, schlägt er fehl.

Wenn keiner der obigen Ergebnisse eine Entscheidung erzeugt, ist ein Test nur erfolgreich, wenn keine Ausnahme ausgelöst wird. Assertionsverletzungen werden auf die gleiche Weise behandelt wie Ausnahmen.

Einrichten und Abbauen

Im Rahmen der Integration mit Testframeworks unterstützt IntelliTest das Erkennen und Ausführen von Setup- und Abrissmethoden.

Beispiel

using Microsoft.Pex.Framework;
using NUnit.Framework;

namespace MyTests
{
    [PexClass]
    [TestFixture]
    public partial class MyTestClass
    {
        [SetUp]
        public void Init()
        {
            // monitored
        }

        [PexMethod]
        public void MyTest(int i)
        {
        }

        [TearDown]
        public void Dispose()
        {
            // monitored
        }
    }
}

Weiterführende Lektüre

Haben Sie Feedback?

Veröffentlichen Sie Ihre Ideen und Featureanfragen in der Entwicklercommunity.

  • Last updated on