J'ai des méthodes dans la base de code qui s'appuient sur application.Current.dispatcher.invoke ... pour vous assurer que les choses fonctionnent sur le fil de l'interface graphique. J'essaie actuellement d'écrire des tests d'unité pour ces méthodes, mais que (comme prévu) Application.Current est NULL, donc je reçois une nullreferenceException.
J'ai essayé d'exécuter les tests concernés dans leur propre AppDomain comme suggéré ici: http://social.msdn.microsoft.com/forums/en-us/wpf/thread/786D5C06-0511-41c0-a6a2-5c4e44f8effb6/
mais application.Current est toujours nul quand je le fais. Ne devriez pas commencer une Appdomain définit l'application.current pour moi? Pourquoi est-il toujours nul?
Mon code:
La classe de base: Le test de l'unité appelante (contenue dans une classe qui hérite d'unitest):
3 Réponses :
Essayez de supprimer l'attribut Serializable et de dériver la classe unittest de MarshalbyRefObject . .
Nope, application.Current est toujours nul alors je reçois toujours une nullreferenceException
Alors pour le moment, j'ai une solution de contournement méchante. J'ai essentiellement déplacé tous les tests qui testent des méthodes qui utilisent l'application.Current à un seul test (elles seront toutes sur le même thread) et appellent une nouvelle application ().
Le code Nasty: P>
[TestClass]
public class IntegrationTests
{
private CedarFile testCedarFile;
/// <summary>
/// This test tests methods that utilize Application.Current.
/// They all have to be in the same test because they must run on the same thread to use the Application instance.
/// </summary>
[TestMethod]
public void IntegrationTests_All()
{
new Application();
QualifierViewModel_FlagsAndLoadDatasets();
CurrentFilesViewModel_AddCedarFile();
CurrentFilesViewModel_AddCedarFileReadOnly();
}
... the private methods to test ...
}
Mes objets à tester étaient simplement accessibles à l'application.Current.properties, donc cela a fonctionné pour moi aussi.
Lors de la tentative d'utilisation de votre solution, je reçois l'erreur suivante "Le thread d'appel peut accéder à cet objet car un fil différent est propriétaire."
Cette solution de contournement fonctionne pour moi:
Pourquoi essayez-vous d'appuyer le code de l'interface graphique? Ce n'est pas strictement un test unitaire si cela dépend de l'interface graphique. Votre code peut-il facturer son utilisation d'applications.current?
C'est un modèle de vue mais apparemment un peu trop étroitement intégré. Je suppose que c'est vraiment plus un test d'intégration qu'un test unitaire. Non, je ne peux pas vraiment prendre en compte l'utilisation de l'application.Current pour le moment (je suis supposé que le test de l'unité, ne touche pas le code).
L'objet
Application.current sera là uniquement si l'interface graphique a été initialisée, par exemple.Dispatcher.Run a été appelé. Ce n'est normalement pas fait (ou recommandé) dans des tests unitaires ...Je peux le simuler en appelant une nouvelle application () (voir ma solution de contournement ci-dessous). Mais je n'aime vraiment pas avoir à mettre tous ces tests en une seule méthode. Ce que j'essayais vraiment de faire était de le faire afin qu'il soit disponible pour des tests dans des méthodes distinctes (et des threads).