Unité testant l'installation d'un client (avec NUnit et MSTest)

J'ai développé une large base de tests unitaires pour l'application de mon entreprise, et dev voudrais passer mes tests unitaires à notre service support pour les aider à déboguer les problèmes d'installation client . J'ai écrit mes tests unitaires en utilisant mstest, donc le support devrait installer Visual Studio sur la machine d'un client s'ils voulaient utiliser mes tests prêts à l'emploi, ce qui est la mauvaise chose à faire, évidemment. J'ai examiné dans l'utilisation de mstest sans VS à l'invite de commande, mais le piratage du registre sur le système d'un client pour lui faire croire que VS est installé n'est pas réalisable non plus. Pour contourner ce problème, j'ai planifié de compiler mes mstests pour nunit en utilisant les informations de this post. Cependant, après la compilation avec NUnit activé, et en ajoutant mon dll d'assemblage de test au runner NUnit, j'obtiens le message d'erreur "Cet assembly n'a pas été construit avec un framework connu".Unité testant l'installation d'un client (avec NUnit et MSTest)

Quelqu'un a-t-il fait cela et a-t-il des trucs et astuces pour le faire fonctionner? Ou est-ce la mauvaise façon de résoudre ce problème? Merci.

Source

2009-10-06 Case

Pour moi, cela semble être une «solution» réalisable: extraire le cœur/le contenu de tous les tests unitaires, les placer dans une solution de bibliothèque de classes distincte, afin de pouvoir le distribuer. Bien sûr, vous devez ensuite séparer les Assert.Functions de la solution de bibliothèque de classes. Appelez les fonctions externalisées à partir du code de test de votre unité ou de votre outil de test externe. Ainsi, la bibliothèque de classes devient le noyau, et le framework MSTest, ou votre propre outil de test externe, devient le wrapper 'GUI'. Cela nécessite un refactoring/réécriture bien sûr, mais les tests réels restent les mêmes, n'est-ce pas? –

Je vais y aller avec votre deuxième réflexion sur ceci: «Ou est-ce la toute mauvaise façon de résoudre ce problème?

Pour résoudre ce problème facilement et ne pas confondre votre service de support, je vous recommande de créer un petit wrapper de ligne de commande autour de la classe de test. Vous pouvez écrire vous-même l'outil de ligne de commande, ou si vous préférez, vous pouvez effectuer les opérations suivantes:

using CSharpTest.Net.Commands; 
static void Main(string[] args) 
{ 
    MyTest testClass = new MyTest(); 
    // optional: testClass.MySetupMethod(); 
    new CommandInterpreter(testClass).Run(args); 
}

Il suffit de construire le code ci-dessus comme une ligne de commande exe dans un nouveau projet de référencement de votre montage d'essai et CSharpTest.Net .Libary.dll. L'espace de noms CSharpTest.Net.Commands est défini dans l'assembly CSharpTest.Net.Libary.dll from this download. Essentiellement le code ci-dessus explorera votre classe de test (appelée MyTest dans l'exemple ci-dessus) et exposera toutes les méthodes publiques comme des commandes qui peuvent être exécutées via la ligne de commande. Par défaut, il fournit une sortie d'aide et définit l'Environment.ExitCode en cas d'échec. Si vous voulez obtenir la fantaisie, vous pouvez décorer vos tests avec une des opérations suivantes:

public class MyTest 
{ 
    [System.ComponentModel.DisplayName("rename-this-function")] 
    [System.ComponentModel.Description("Some description for tech-support")] 
    [System.ComponentModel.Browsable(true | false)] 
    public void TestSomeFunction() 
    { ... } 
}

(Et oui, je reconnais que je suis mon propre sans vergogne de brancher le code d'un petit bits :)

Source

2009-10-06 03:08:19

Intéressant. Je suis allé un peu plus bas depuis hier, fouettant une petite application de console qui a utilisé la réflexion pour appeler les méthodes de test dans ma classe, mais a rencontré des problèmes avec TestContext et les méthodes d'initialisation de classe. On dirait que vous construisez vous-même vos initialiseurs par essai? – Case

Ahh, non, j'ai oublié les étranges dépendances d'initialisation de MsTest. Je pense qu'ils l'ont fait intentionnellement pour vous forcer à continuer à utiliser MsTest :) En tout cas, pouvez-vous briser vos dépendances sur les choses spécifiques à MsTest? Sinon, je devrais retirer ma recommandation originale et vous suggérer d'écrire un utilitaire en ligne de commande en dehors des tests. Gardez-le automatisé dans la construction en parallèle avec les tests pour s'assurer qu'il continue à fonctionner. –

C'est la réponse la plus proche de ce que j'ai fini par faire - qui était juste une autre version de mon code qui a fonctionné sur NUnit avec un sous-ensemble des tests. – Case

Ma préoccupation serait quelqu'un qui ajoute un test unitaire (ou test d'intégration déguisé en test unitaire) que vous exécutez par inadvertance sur votre base de données client. Bien sûr, je fais des suppositions comme si vous aviez une base de données, mais cela semble une approche risquée, sauf si vous pouvez être sûr que vos tests sont non destructifs, maintenant et dans le futur.

Avez-vous connecté votre application? C'est la façon traditionnelle d'aider, et il y a many tools pour vous aider.

Source

2009-10-06 03:25:46 si618

Unité testant l'installation d'un client (avec NUnit et MSTest)

Répondre

Questions connexes