Comment configurer les tests unitaires pour Visual Studio C++ ?

Question

J'ai du mal à comprendre comment mettre en place le cadre de test et le rendre utilisable dans le système de gestion de l'information de l'entreprise. Visual Studio 2008 pour C++ vraisemblablement avec la suite de tests unitaires intégrée.

Tout lien ou tutoriel serait apprécié.

Answer 1

Cette page peut vous aider, il passe en revue un certain nombre de cadres de tests unitaires C++ :

• CppUnit
• Boost.Test
• CppUnitLite
• NanoCppUnit
• Unité++
• CxxTest

Vérifiez CPPUnitLite o CPPUnitLite2 .

CPPUnitLite a été créé par Michael Feathers, qui a initialement porté JUnit de Java vers C++ sous le nom de CPPUnit (CPPUnit tente d'imiter le modèle de développement de JUnit - mais C++ n'a pas les caractéristiques de Java [par exemple la réflexion] pour le rendre facile à utiliser).

CPPUnitLite tente de créer un véritable cadre de test de style C++, et non un cadre Java porté en C++. (Je paraphrase l'article de Feather intitulé Travailler efficacement avec le code hérité livre). CPPUnitLite2 semble être une autre réécriture, avec plus de fonctionnalités et de corrections de bogues.

Je viens aussi de tomber sur UnitTest++ qui inclut des éléments de CPPUnitLite2 et d'un autre cadre.

Microsoft a publié WinUnit .

Vérifiez également Attrapez o Doctest

Answer 2

Il existe un moyen de tester le C++ non géré à l'aide du cadre de test intégré à Visual Studio 2008. . Si vous créez un projet de test C++, en utilisant C++/CLI, vous pouvez alors faire des appels à une DLL non gérée. Vous devrez faire passer le support du Common Language Runtime de /clr à /clr:safe si vous voulez tester du code écrit en C++ non géré.

J'ai des détails étape par étape sur mon blog ici : http://msujaws.wordpress.com/2009/05/06/unit-testing-mfc-with-mstest/

Answer 3

Voici l'approche que j'utilise pour tester le module IIS URL Rewrite de Microsoft (elle est basée sur la ligne de commande, mais devrait aussi fonctionner pour VS) :

1. Assurez-vous que vos fichiers d'en-tête sont consommables en déplaçant le code source dans des fichiers cpp et en utilisant la déclaration forward si nécessaire.
2. Compilez votre code pour le tester en tant que bibliothèque (.lib)
3. Créez votre projet UnitTest en C++ avec le support CLR.
4. Incluez vos fichiers d'en-tête.
5. Incluez vos fichiers .lib.
6. Ajouter une référence à Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
7. Utilisez une très petite classe pour déclarer votre test unitaire et passez du code géré au code C++/Natif comme ceci (il peut y avoir des fautes de frappe) :

Voici un exemple :

// Example
#include "stdafx.h"
#include "mstest.h"

// Following code is native code.
#pragma unmanaged
void AddTwoNumbersTest() {
  // Arrange
  Adder yourNativeObject;
  int expected = 3;
  int actual;
  // Act
  actual = yourNativeObject.Add(1, 2);
  // Assert
  Assert::AreEqual(expected, actual, L"1 + 2 != 3");
}

// Following code is C++/CLI (Managed)
#pragma managed
using namespace Microsoft::VisualStudio::TestTools::UnitTesting;
[TestClass]
public ref class TestShim {
public:
  [TestMethod]
  void AddTwoNumbersTest() {
     // Just jump to C++ native code (above)
     ::AddTwoNumbersTest();
  }
};

Avec cette approche, les gens n'ont pas à apprendre trop de choses sur le C++/CLI, tous les tests réels seront effectués en C++ natif et la classe TestShim sera utilisée pour "publier" le test à MSTest.exe (ou le rendre visible).

Pour ajouter de nouveaux tests, il suffit de déclarer une nouvelle méthode [TestMethod] void NewTest(){::NewTest();} et une nouvelle fonction native void NewTest(). Pas de macros, pas d'astuces, tout simplement.

Maintenant, le fichier heade est facultatif, mais il peut être utilisé pour exposer les méthodes de la classe Assert avec des signatures natives C++ (par exemple wchar_t* au lieu de Stirng^), ce qui permet de rester proche de C++ et loin de C++/CLI :

Voici un exemple :

// Example
#pragma once
#pragma managed(push, on)
using namespace System;
class Assert {
public:
    static void AreEqual(int expected, int actual) {
        Microsoft::VisualStudio::TestTools::UnitTesting::Assert::AreEqual(expected, actual);
    }

    static void AreEqual(int expected, int actual, PCWSTR pszMessage) {
        Microsoft::VisualStudio::TestTools::UnitTesting::Assert::AreEqual(expected, actual, gcnew String(pszMe
ssage));
    }

    template<typename T>
    static void AreEqual(T expected, T actual) {
        Microsoft::VisualStudio::TestTools::UnitTesting::Assert::AreEqual(expected, actual);
    }

    // Etcetera, other overloads...
}
#pragma managed(pop)

HTH

Answer 4

Personnellement, je préfère WinUnit puisqu'il ne me demande pas de écrire quoi que ce soit, sauf pour mes tests (Je construis une .dll comme test, pas un exe). Je construis simplement un projet, et je dirige WinUnit.exe vers mon répertoire de sortie de test et il exécute tout ce qu'il trouve. Vous pouvez téléchargez le projet WinUnit ici . (MSDN exige maintenant que vous téléchargiez le numéro entier, et non l'article. WinUnit y est inclus).

Answer 5

Le cadre inclus avec VS9 es .NET, mais vous pouvez écrire des tests en C++/CLI, donc tant que vous êtes à l'aise pour apprendre certains aspects de .NET, vous devriez être capable de tester la plupart des codes C++.

boost.test et googletest semblent être assez similaires, mais adaptées à des usages légèrement différents. Les deux ont un composant binaire, vous aurez donc besoin d'un projet supplémentaire dans votre solution pour compiler et exécuter les tests.

Le cadre que nous utilisons est CxxTest qui est beaucoup plus léger ; il ne s'agit que d'en-têtes, et utilise un script Perl ( !) script pour extraire les informations de la suite de tests de vos en-têtes (les suites héritent de CxxTest::Base, tous les noms de vos méthodes de test commencent par "test"). Évidemment, cela nécessite que vous obteniez Perl de une source o un autre ce qui ajoute de la complexité à la configuration de votre environnement de construction.