Limites d'utilisation de C ++ / CLI avec NUnit

Question

Cette réponse à une question sur les frameworks de tests unitaires C ++ suggère une possibilité cela ne m’était pas arrivé auparavant: utiliser C ++ / CLI et NUnit pour créer des tests unitaires pour le code C ++ natif.

Nous utilisons NUnit pour nos tests C #, la possibilité de l'utiliser également pour C ++ semble donc séduisante.

Comme je n'ai jamais utilisé le C ++ géré, mon souci est de savoir s'il existe des limitations pratiques à cette approche? Est-ce que beaucoup d'entre vous font cela? Si oui, quelle a été votre expérience?

Answer 1

Nous le faisons tout le temps. Nous avons beaucoup d'assemblages écrits avec C ++ / CLI et utilisons C # et NUnit pour les tester. En fait, puisque notre objectif est de fournir des assemblys qui fonctionnent bien avec C #, cela garantit que nous avons réussi.

Vous pouvez également écrire des tests NUnit en C ++ / CLI et appeler C ++ non géré. Le meilleur moyen consiste probablement à conserver votre C ++ non géré pur dans une bibliothèque, puis à créer un assemblage de test utilisant NUnit et des liens vers la bibliothèque.

Answer 2

Cela fonctionne très bien et vous donne l’avantage d’avoir des tests paramétrés ainsi qu’un environnement de test et une infrastructure communs si vous êtes dans un environnement mixte.

Il existe deux inconvénients, dont aucun n'est grave dans la plupart des cas:

1. Si vous êtes vraiment pointilleux, les tests ne sont plus exécutés dans un environnement purement natif. Il est donc possible que quelque chose fonctionne, mais échoue à l'exécution. Je pense que vous devriez faire quelque chose d'assez exotique pour que cela compte.

2. Vous voulez que votre code C ++ puisse être inclus dans un programme C ++ / CLI. Parfois, cela peut entraîner des conflits avec les en-têtes et obliger votre code à compiler correctement avec UNICODE. En général, c’est une bonne chose, car elle permet de découvrir des morceaux de code cruels (comme une utilisation incohérente des variantes Ansi des appels Win32). N'oubliez pas que seuls les en-têtes sont inclus, ce qui montre que vous exposez les en-têtes à un niveau trop élevé - certains de vos inclus devraient probablement figurer dans vos fichiers de mise en œuvre cpp.

Answer 3

D'après mon expérience, il n'est pas possible d'utiliser NUnit pour tester le code natif C ++ via C ++ / CLI car vous rencontrerez des difficultés pour charger et utiliser le code natif.

J'ai essayé d'utiliser nunit pour charger une dll de test de base c ++ / cli liée à "simplement un thread". qui est une implémentation de la bibliothèque de threads standard c ++. Les dlls de test ne se chargeront même pas avec la dernière version de NUnit (2.6.2).

Alors certainement pas la voie à suivre!

Answer 4

Je n'en ai jamais utilisé, mais n'y a-t-il pas de port? Peut-être que http://cunit.sourceforge.net/documentation.html pourrait fonctionner pour vous.

Answer 5

La préoccupation majeure est la courbe d'apprentissage du langage C ++ / CLI (anciennement Managed C ++) lui-même, si les tests doivent être compris ou gérés par des développeurs non-C ++.

Pour pouvoir contribuer à un projet de test C ++ CLI / NUnit et résoudre les divers problèmes qui se posent entre les interfaces de code natif géré, il faut au moins 1 à 2 années d'expérience de la programmation orientée objet C ++. (Par contribution, j'entends pouvoir travailler de manière autonome et créer des objets fictifs, implémenter et utiliser des interfaces natives en C ++ / CLI, etc. pour répondre à tous les besoins en matière de tests.)

Certaines personnes ne comprendront peut-être jamais assez C ++ / CLI pour pouvoir contribuer.

Pour certains types de bibliothèques logicielles natives avec des besoins de test très exigeants, C ++ / CLI / NUnit est la seule combinaison qui répondra à tous les besoins de test unitaire tout en maintenant le code de test agile et en mesure de réagir aux changements. Je recommande le livre Modèles de test xUnit: code de test de refactoring pour suivre cette direction. .