[TestMethod]
public void SomeTestMethod()
{
string input = "some looooong input...";
var proc = new Processor()
string result = proc.DoSomething(input);
Assert.Equals("good", result);
}
If I'm writing a unit test and I have an input that is extremely long (such as EDI transactions), should I just paste that into my test method as a long string?Others have suggested I should paste that long string into a file and treat that file as an embedded resource in my test project. If I do something like that and I need different inputs for each of my tests, I could see a lot of files piling up and becoming hard to maintain. Are there any best practices surrounding this? Should I just continue pasting these long strings into my test methods?
6 Réponses :
J'ai toujours mis de longues chaînes d'essai dans des ressources et maintenez une nommée cohérente entre les tests et leurs ressources pour conserver la cartographie facile. J'utilise le même nom pour la ressource et le test. Lorsque j'ai besoin de plusieurs ressources pour un test, j'ajoute un suffixe 1 , 2 , 3 , et ainsi de suite.
Cela laissera également IntelliSense vous donner un coup d'oeil à la ressource - cool
Si c'est quelque chose de rapide que je ne me soucie pas de le laisser tomber dans le code. Puisque je suis plus que probablement testant un concept.
Si son code, vous allez conserver comme des tests ou un code de production, utilisez un fichier de ressource soit en tant que ressource intégrée, soit à l'aide d'un fichier RESX, que vous êtes toujours plus à l'aise.
Vous pouvez utiliser un constructeur de chaînes différent pour créer une très longue chaîne de caractères répétés, tels que ceci:
string input = new string('x', 1024 * 1024 / 2);
Eh bien, millions de X ne me regarde pas comme une transaction EDI :)
Vrai, mais non plus «Certaines entrées Looooong ...», il pourrait être que vous auriez besoin de faire la première partie de la chaîne contenir des informations d'en-tête valides, mais remplissez ensuite la majeure partie de la chaîne avec une méthode telle que celle-ci. Cette approche peut ne pas fonctionner en fonction de ce que vous devez tester, mais si vous avez juste besoin de quelque chose d'extrêmement long, il fournit une bonne approche pour créer une longue chaîne.
Ceci est juste une réponse "opinionnée" depuis que je n'ai jamais vu de meilleure pratique à ce sujet;
Je travaille avec des fichiers EDI et nos cas de test sont généralement autonomes avec des données de test collées comme vous le faites, dans notre cas, comme des constantes définies en dehors du test lui-même de ne pas encombrer le code de test réel.
Nous avons constaté que la gestion des fichiers externes est sujette d'erreur en soi.
Je testais un peu de regexp qui contre le fichier. Ce que j'ai fait est que je copie a collé le contenu du fichier dans la classe de test en tant que propriété normale, mais j'ai utilisé les balises #region pour le cacher. Je n'ai pas besoin de voir 200 lignes de texte à chaque fois que j'ouvre cette classe de test. C'est aussi l'un des rares cas où je trouve l'étiquette #region utile.
sans savoir En tant que tel, je stockais toutes mes données de test dans un fichier XML et le chargerais dans le test, exécutant le même test pour chaque entrée (si vous souhaitez tester des quantités graves de données - vous pouvez utiliser une base de données). Il n'est pas nécessaire d'écrire des tests séparés pour chaque entrée.
Une approche très propre et élégante sur la manière dont cela se fait dans Mstest est décrit ici . le code du processeur , comme je le vois, processeur doit avoir des tests simples, rapides et d'unité couvrant ses travaux internes, tandis que des tests comme MesestestMethod doit être considéré comme tests d'intégration .