Share via

Usare il framework MSTest negli unit test

  • Articolo

Il framework MSTest supporta unit test in Visual Studio. Usare le classi e i membri nello spazio dei Microsoft.VisualStudio.TestTools.UnitTesting nomi quando si codificano unit test. È anche possibile usarli quando si affina uno unit test generato dal codice.

Membri del framework

Per offrire una panoramica più accurata del framework di testing unità, in questa sezione i membri dello spazio dei nomi Microsoft.VisualStudio.TestTools.UnitTesting vengono organizzati in gruppi di funzionalità correlate.

Nota

Gli elementi dell'attributo, i cui nomi terminano con "Attribute", possono essere usati con o senza "Attribute" alla fine e per i costruttori senza parametri con o senza parentesi. Ad esempio, gli esempi di codice seguenti funzionano in modo identico:

[TestClass()]

[TestClassAttribute()]

[TestClass]

[TestClassAttribute]

Attributi usati per identificare classi e metodi di test

Ogni classe di test deve avere l'attributo TestClass e ogni metodo di test deve avere l'attributo TestMethod. Per altre informazioni, vedere Anatomia di un unit test.

Testclassattribute

L'attributo TestClass contrassegna una classe che contiene test e, facoltativamente, inizializzare o pulire i metodi.

Questo attributo può essere esteso per aggiornare o estendere il comportamento.

Esempio:

[TestClass]
public class MyTestClass
{    
}

TestMethodAttribute

L'attributo TestMethod viene usato all'interno di per TestClass definire il metodo di test effettivo da eseguire.

Il metodo deve essere un metodo di istanza definito come public void o public Task (facoltativamente async) ed essere senza parametri.

Esempio

[TestClass]
public class MyTestClass
{
    [TestMethod]
    public void TestMethod()
    {
    }
}

[TestClass]
public class MyTestClass
{
    [TestMethod]
    public async Task TestMethod()
    {
    }
}

Attributi usati per i test basati sui dati

Usare gli elementi seguenti per configurare unit test basati sui dati. Per altre informazioni, vedere Creare uno unit test basato sui dati e Usare un file di configurazione per definire un'origine dati.

Datarow

DataRowAttribute consente di fornire dati inline usati quando si richiama il metodo di test. Può apparire una o più volte in un metodo di test. Deve essere combinato con TestMethodAttribute o DataTestMethodAttribute.

Il numero e i tipi di argomenti devono corrispondere esattamente alla firma del metodo di test.

Esempi di chiamate valide:

[TestClass]
public class TestClass
{
    [TestMethod]
    [DataRow(1, "message", true, 2.0)]
    public void TestMethod1(int i, string s, bool b, float f) {}
    
    [TestMethod]
    [DataRow(new string[] { "line1", "line2" })]
    public void TestMethod2(string[] lines) {}

    [TestMethod]
    [DataRow(null)]
    public void TestMethod3(object o) {}

    [TestMethod]
    [DataRow(new string[] { "line1", "line2" }, new string[] { "line1.", "line2." })]
    public void TestMethod4(string[] input, string[] expectedOutput) {}
}

Si noti che è anche possibile usare la params funzionalità per acquisire più input di DataRow.

[TestClass]
public class TestClass
{
    [TestMethod]
    [DataRow(1, 2, 3, 4)]
    public void TestMethod(params int[] values) {}
}

Esempi di combinazioni non valide:

[TestClass]
public class TestClass
{
    [TestMethod]
    [DataRow(1, 2)] // Not valid, we are passing 2 inline data but signature expects 1
    public void TestMethod1(int i) {}

    [TestMethod]
    [DataRow(1)] // Not valid, we are passing 1 inline data but signature expects 2
    public void TestMethod2(int i, int j) {}

    [TestMethod]
    [DataRow(1)] // Not valid, count matches but types do not match
    public void TestMethod3(string s) {}
}

Nota

A partire da MSTest v3, quando si vogliono passare esattamente 2 matrici, non è più necessario eseguire il wrapping della seconda matrice in una matrice di oggetti. Prima: [DataRow(new string[] { "a" }, new object[] { new string[] { "b" } })] In v3 e versioni successive: [DataRow(new string[] { "a" }, new string[] { "b" })]

È possibile modificare il nome visualizzato usato in Visual Studio e i logger per ogni istanza di DataRowAttribute impostando la DisplayName proprietà .

[TestClass]
public class TestClass
{
    [TestMethod]
    [DataRow(1, 2, DisplayName= "Functional Case FC100.1")]
    public void TestMethod(int i, int j) {}
}

È anche possibile creare un attributo di riga di dati specializzato ereditando .DataRowAttribute

[AttributeUsage(AttributeTargets.Method, AllowMultiple = true)]
public class MyCustomDataRowAttribute : DataRowAttribute
{
}

[TestClass]
public class TestClass
{
    [TestMethod]
    [MyCustomDataRow(1)]
    public void TestMethod(int i) {}
}

Attributi usati per fornire l'inizializzazione e le operazioni di pulizia

Al momento specificato viene chiamato un metodo decorato con uno degli attributi seguenti. Per altre informazioni, vedere Anatomia di un unit test.

Assemblaggio

AssemblyInitialize viene chiamato subito dopo il caricamento dell'assembly e AssemblyCleanup viene chiamato subito prima che l'assembly venga scaricato.

I metodi contrassegnati con questi attributi devono essere definiti come static void o static Task, in un TestClassoggetto e vengono visualizzati una sola volta. La parte di inizializzazione richiede un argomento di tipo TestContext e l'argomento cleanup no.

[TestClass]
public class MyTestClass
{
    [AssemblyInitialize]
    public static void AssemblyInitialize(TestContext testContext)
    {
    }

    [AssemblyCleanup]
    public static void AssemblyCleanup()
    {
    }
}

[TestClass]
public class MyOtherTestClass
{
    [AssemblyInitialize]
    public static async Task AssemblyInitialize(TestContext testContext)
    {
    }

    [AssemblyCleanup]
    public static async Task AssemblyCleanup()
    {
    }
}

Classe

ClassInitialize viene chiamato subito prima del caricamento della classe (ma dopo il costruttore statico) e ClassCleanup viene chiamato subito dopo che la classe viene scaricata.

È possibile controllare il comportamento di ereditarietà: solo per la classe corrente che usa InheritanceBehavior.None o per tutte le classi derivate tramite InheritanceBehavior.BeforeEachDerivedClass.

È anche possibile configurare se la pulizia della classe deve essere eseguita alla fine della classe o alla fine dell'assembly (Non è più supportato a partire da MSTest v4 perché EndOfClass è il comportamento predefinito e solo di pulizia della classe).

I metodi contrassegnati con questi attributi devono essere definiti come static void o static Task, in un TestClassoggetto e vengono visualizzati una sola volta. La parte di inizializzazione richiede un argomento di tipo TestContext e l'argomento cleanup no.

[TestClass]
public class MyTestClass
{
    [ClassInitialize]
    public static void ClassInitialize(TestContext testContext)
    {
    }

    [ClassCleanup]
    public static void ClassCleanup()
    {
    }
}

[TestClass]
public class MyOtherTestClass
{
    [ClassInitialize]
    public static async Task ClassInitialize(TestContext testContext)
    {
    }

    [ClassCleanup]
    public static async Task ClassCleanup()
    {
    }
}

  Test

TestInitialize viene chiamato subito prima dell'avvio del test e TestCleanup viene chiamato subito dopo il completamento del test.

TestInitialize è simile al costruttore della classe, ma è in genere più adatto per inizializzazioni lunghe o asincrone. Viene TestInitialize sempre chiamato dopo il costruttore e chiamato per ogni test (inclusa ogni riga di dati di test basati sui dati).

è TestCleanup simile alla classe Dispose (o DisposeAsync) ma è in genere più adatta per le operazioni di pulizia asincrone o lunghe. Viene TestCleanup sempre chiamato poco prima di DisposeAsync/Dispose e viene chiamato per ogni test (inclusa ogni riga di dati di test basati sui dati).

I metodi contrassegnati con questi attributi devono essere definiti come void o Task, in un TestClassoggetto , senza parametri e vengono visualizzati uno o più volte.

[TestClass]
public class MyTestClass
{
    [TestInitialize]
    public void TestInitialize()
    {
    }

    [TestCleanup]
    public void TestCleanup()
    {
    }
}

[TestClass]
public class MyOtherTestClass
{
    [TestInitialize]
    public async Task TestInitialize()
    {
    }

    [TestCleanup]
    public async Task TestCleanup()
    {
    }
}

Gli unit test possono verificare il comportamento specifico dell'applicazione in base all'uso di vari tipi di asserzioni, eccezioni e attributi. Per altre informazioni, vedere Uso di classi Assert.

Classe TestContext

I seguenti attributi e i valori ad essi assegnati sono visualizzati nella finestra Proprietà di Visual Studio per un determinato metodo di test. Questi attributi non devono essere accessibili tramite il codice dello unit test. Influiscono invece sui modi in cui viene usato o eseguito lo unit test, ovvero manualmente tramite l'IDE di Visual Studio o dal motore di test di Visual Studio. Ad esempio, alcuni di questi attributi sono visualizzati come colonne nella finestra Gestione test e nella finestra Risultati del test, quindi è possibile usarli per raggruppare e ordinare i test e i risultati dei test. Uno di questi attributi è TestPropertyAttribute, che viene usato per aggiungere metadati arbitrari agli unit test. Ad esempio, è possibile usarlo per archiviare il nome di un "test pass" illustrato da questo test, contrassegnando lo unit test con [TestProperty("TestPass", "Accessibility")]. In alternativa, è possibile usarlo per archiviare un indicatore del tipo di test Con [TestProperty("TestKind", "Localization")]. La proprietà creata usando questo attributo e il valore di proprietà assegnato vengono entrambi visualizzati nella finestra Proprietà di Visual Studio, sotto l'intestazione Specifico del test.

DeploymentItemAttribute

Il framework MSTest V2 introdotto DeploymentItemAttribute per copiare file o cartelle specificati come elementi di distribuzione nella directory di distribuzione (senza aggiungere un percorso di output personalizzato i file copiati saranno nella cartella TestResults all'interno della cartella del progetto). La directory di distribuzione è la posizione in cui sono presenti tutti gli elementi di distribuzione insieme alla DLL del progetto di test.

Può essere usato nelle classi di test (classi contrassegnate con TestClass attributo) o nei metodi di test (metodi contrassegnati con TestMethod attributo).

Gli utenti possono avere più istanze dell'attributo per specificare più di un elemento.

E qui è possibile vedere i relativi costruttori.

Esempio

[TestClass] 
[DeploymentItem(@"C:\classLevelDepItem.xml")]   // Copy file using some absolute path
public class UnitTest1
{
    [TestMethod]
    [DeploymentItem(@"..\..\methodLevelDepItem1.xml")]   // Copy file using a relative path from the dll output location
    [DeploymentItem(@"C:\DataFiles\methodLevelDepItem2.xml", "SampleDataFiles")]   // File will be added under a SampleDataFiles in the deployment directory
    public void TestMethod1()
    {
        string textFromFile = File.ReadAllText("classLevelDepItem.xml");
    }
}

Classi di configurazione di test

Attributi usati per generare report

Gli attributi in questa sezione correlano il metodo di test che decorano alle entità nella gerarchia del progetto di un progetto team di Team Foundation Server.

Classi usate con funzioni di accesso private

È possibile generare uno unit test per un metodo privato. Questa generazione crea una classe di funzione di accesso privata, che crea un'istanza di un oggetto della classe PrivateObject. La classe PrivateObject è una classe wrapper che usa la reflection come parte del processo della funzione di accesso privata. La classe PrivateType è simile, ma viene usata per chiamare metodi statici privati anziché metodi di istanza privata.

Vedi anche