NUnit 3: Interdire les tests à s'exécuter en parallèle
J'ai le dernier NUnit (3.2.0) installé et j'ai tous mes tests exécutés en parallèle. Cela pourrait ressembler à un comportement souhaitable, mais je ne l'ai pas demandé et en fait, cela a cassé certains de mes tests. J'ai une initialisation dans [OneTimeSetUp] Qui dépend du thread et il semble que je ne puisse rien faire pour forcer NUnit à exécuter mes tests séquentiellement. J'ai lu le documentation et il indique que par défaut les tests ne sont pas exécutés en parallèle mais en fait ils le sont!
De plus, j'ai essayé d'ajouter l'attribut suivant: [Assembly: Parallelizable(ParallelScope.None)] - pas de chance.
Quelqu'un sait-il comment changer ce comportement?
P.S. Je l'exécute avec ReSharper mais j'essaie également avec le complément MSVS.
UPD: J'utilise MVVM Light DispatcherHelper.Initialize() (à l'intérieur de [OneTimeSetUp]) Pour stocker l'objet répartiteur qui est plus tard utilisé par quelques tests. Si les threads sont différents (entre un test et la méthode d'installation), l'action sous test est exécutée de manière asynchrone et mes tests échouent.
J'ai vérifié les identifiants des threads dans différents tests et ils sont tous différents.
UPD2: Extrait de la documentation:
Le framework NUnit 3.0 peut exécuter des tests en parallèle au sein d'un assembly . Il s'agit d'une fonction complètement distincte de Engine Parallel Test Execution, bien qu'il soit possible d'utiliser les deux dans le même cycle de test.
Par défaut, aucune exécution parallèle n'a lieu . Les attributs sont utilisés pour indiquer quels tests peuvent s'exécuter en parallèle et comment ils sont liés à d'autres tests.
Si cela ne signifie pas que les tests au sein d'un assembly ne doivent pas être exécutés en parallèle jusqu'à ce qu'ils soient explicitement spécifiés, qu'est-ce que cela signifie? Et pourquoi [Assembly: Parallelizable(ParallelScope.None)] n'a aucun effet sur l'exécution parallèle des tests?
UPD3: La réponse à la question peut être trouvée ci-dessous mais si vous êtes coincé (comme je l'étais) avec la DispatcherHelper.Initialize() vous avez juste besoin pour supprimer cette initialisation du OneTimeSetUp et mettre les lignes suivantes dans chaque test qui utilise un répartiteur:
DispatcherHelper.Reset();
DispatcherHelper.Initialize();
NUnit ne garantit pas que tous vos tests s'exécuteront sur le même thread, donc l'observation que vos tests s'exécutent sur des threads différents ne signifie pas qu'ils s'exécutent en parallèle.
La documentation indique seulement que les tests s'exécuteront séquentiellement ou en parallèle. Vous pouvez comprendre que cela signifie qu'ils s'exécutent sur le même thread, mais il existe de nombreuses raisons pour lesquelles l'implémentation interne peut nécessiter des tests pour s'exécuter sur différents threads. Timeout est un exemple, où nous générons un thread et le tuons si le test expire, mais il y en a beaucoup d'autres.
Les exécutions de tests parallèles sont nouvelles pour NUnit 3, donc l'implémentation interne a changé de NUnit 2. Un attribut qui force tous les tests d'un thread à s'exécuter sur le même thread peut être utile, alors n'hésitez pas à soumettre un demande d'amélioration .
Désolé, je ne suis pas familier avec MVVM Light, donc je ne peux pas suggérer de moyens de marshaling vers le thread OneTimeSetup.
Mise à jour - Comme il s'agit d'une utilisation courante avec le web et asynchrone, l'équipe NUnit a décidé de fournir un attribut qui demandera que des tests soient exécutés sur le même thread comme OneTimeSetup du luminaire. Ce sera dans la prochaine version, 3.4, ou dans une version de correctif 3.2.1. Si vous souhaitez suivre les progrès, consultez les issue et les pull request .
Mise à jour 2 - Vous pouvez maintenant ajouter SingleThreadedAttribute à un TestFixture pour indiquer au coureur que le OneTimeSetUp, OneTimeTearDown et tous les tests enfants doivent s'exécuter sur le même thread.
Vous pouvez empêcher les tests de s'exécuter en parallèle en ajoutant l'attribut [NonParallelizable] , qui peut être ajouté au niveau test, classe et assembly.