Saut de DesignTime lors du test de débogage

En ce moment je développe un UnitTest pour un CustomControl. Dans ce contrôle, il y a du code, qui n'est excuté que lorsque la méthode appelée n'est pas appelée dans DesignTime. Lorsque j'exécute le test, le code donné n'est pas exécuté, car le contexte actuel semble être le DesignTime.Saut de DesignTime lors du test de débogage

Exemple:

public void SomeMethod() // EDIT: this is the OnLoaded Event for example. 
{ 
    if(IsNotInDesignMode()) // This is implemented somewhere else. 
    { 
     // I want this to be called in the Test Execution. 
     DoSomething(); 
    } 
}

EDIT: On dirait que ma première tentative était pas assez claire, alors voici une autre description.

Existe-t-il un moyen d'indiquer à ma méthode/classe de test d'exécuter le test en tant que version d'exécution? Je ne veux pas changer les propriétés ou les méthodes dans mon CustomControl. Et je n'ai pas acccess à la méthode IsNotInDesignMode() (en se moquant d'elle par exemple), car elle est implémentée dans une bibliothèque externe.

EDIT 2: Voir Code.

Merci de m'avoir aidé.

Source

2017-10-18 Febertson

Vous ne pouvez pas "sauter hors du temps de conception". Votre contrôle utilisateur est affiché dans un concepteur ou affiché lors de l'exécution. Expliquez ce que vous essayez de faire exactement et expliquez ce que vous entendez par «sauter hors du temps de conception». Plus de contexte est nécessaire pour répondre à cela. Si vous voulez dire que vous voulez que la propriété 'IsNotInDesignMode' obtienne une certaine valeur pendant que l'unité teste le contrôle, alors créez un paramètre constructeur qui définit cette propriété, ou attribuez-le directement à partir de votre test unitaire. – CodeCaster

Je comprends que vous pourriez ne pas comprendre mon problème. Mais pourquoi l'avez-vous marqué comme doublon? Vous empêchez les autres utilisateurs d'ouvrir ma question et d'essayer de donner une réponse. Le lien que vous avez fourni est une question complètement différente. – Febertson

La description du problème que vous donnez est répondue par le doublon: vous ne pouvez que _détecter_, pas modifier le temps de conception - c'est une propriété en lecture seule. Donc, si vous voulez que votre vrai problème soit résolu, lisez [ask] et [edit] votre question afin qu'elle puisse être réellement répondue, et je serai heureux de rouvrir. – CodeCaster

Il semble que vous ayez une logique métier mélangée avec la logique de vue. Il n'y a aucune raison de tester l'interface graphique.

Je vous recommande d'encapsuler votre logique métier dans ses propres classes. Puis appelez les opérations spécifiques de la vue (s). Une fois cela fait, votre test unitaire peut tester la logique métier directement et ne pas gérer le temps de conception.

Source

2017-10-18 20:04:41 OmegaMan

Merci pour cette première approche, mais il n'y a pas de logique métier dans la méthode. Le SomeMethod pourrait être le LoadedEvent par exemple. Et je ne peux pas mettre mes affaires dans le Constructeur ou ailleurs, parce que mes valeurs dont j'ai besoin ne sont pas encore définies. – Febertson

@Febertson Avec MVVM correct, vous devriez pouvoir avoir des projets séparés pour view et viewmodel. Les tests unitaires ne doivent même pas faire référence au projet de vue, car ils n'ont besoin que du viewmodel et de la BLL. – grek40

Je comprends ce que vous dites. Mais j'ai un contrôle qui a une nouvelle propriété qui génère des éléments enfants dynamiques. C'est la fonction que je veux tester. Créez le contrôle dans mon test. Définissez la nouvelle propriété et vérifiez si les enfants sont créés correctement. Cette fonction est strictement sur le côté de l'interface utilisateur. Peut-être que cela ne devrait pas ou ne peut pas être testé avec UnitTests. C'est ce que j'essaie d'évaluer en ce moment. – Febertson

Saut de DesignTime lors du test de débogage

Répondre

Questions connexes