Je suis une sorte de nouveau à TDD. J'ai commencé à créer les propriétés dont j'ai besoin sur le modèle d'affichage comme une seule propriété automatique.
public string Firstname
{
get { return _contact.FirstName; }
set
{
if (_contact.FirstName == value)
return;
_contact.FirstName = value;
RaisePropertyChanged(() => Firstname);
}
}
6 Réponses :
Vous devez avoir un autre test qui affirme réellement que vos incendies de biens immobilisés.
Lorsque vous effectuez ce test, votre propriété auto devrait échouer, car l'événement ne tiendra jamais.
Merci beaucoup pour l'article, je l'étudierai bientôt et voyez ce que j'apprendrai d'autre.
Malheureusement, le lien est mort et aucune information de l'article est copiée dans la réponse.
Vous pouvez faire quelque chose comme ceci:
[TestMethod]
[Tag("Property")]
public void FirstNameTest()
{
bool didFire = false;
ViewModel = new CustomerViewModel();
ViewModel.PropertyChanged += (s, e) =>
{
didFire = true;
Assert.AreEqual("Firstname", e.PropertyName);
Assert.AreEqual("Test", ViewModel.Firstname);
};
ViewModel.Firstname = "Test";
Assert.IsTrue(didFire);
}
Merci beaucoup pour la réponse claire. Ça fonctionne maintenant. Cependant, l'affirmation jette une assertFailedException à la dernière ligne. Je dois continuer à continuer puis je vois que le test a échoué dans les résultats. J'utilise Silverlight 4 Unité Toolkit de test avec VS 2010. Ceci est assez gênant, est-il possible de supprimer cela, je ne veux pas f5 sur 50 tests unitaires plus tard, si quelque chose s'est mal passé. :)
Il suffit de ne pas exécuter les tests en mode de débogage :)
Je l'ai couru sous la sortie et cela vient toujours avec une interruption. C'est vraiment agaçant. J'utilise des tests unitaires sous Silverlight 4 Cadre de test. Toute idée de quiconque?
je l'ai trouvé. Il n'a rien à voir avec le mode de débogage La réponse est ici: blog.benday .Com / Archive / 2010/08/18 / 23287.aspx
@Antoine Aubry, mais il peut alternativement sur le bouton Continuer ou appuyer sur F5. C'est le même comportement.
Un test doit échouer sauf si le comportement qu'il est testé est déjà implémenté.
Pour tester les notifications de changement de propriété lors de ma dernière tentative, j'ai créé une classe d'assistance qui m'a aidé à écrire des tests comme celui-ci (c'est en nunit)
Vous pouvez essayer d'écrire le test pour être asynchrone. Considérez cette méthode de test:
using Microsoft.Silverlight.Testing;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace Foo.Example.Test
{
[TestClass]
public class Tests : SilverlightTest
{
// ... tests go here
}
}
Merci beaucoup. Cette réponse m'a aidé à un niveau de Silverlight encore plus. Cependant, j'aimerais commenter une chose, si vous utilisez EnQuuecallback sans aucun cas d'enqueuconditionnel, ce serait la même que si vous effectuez les appels synchrones de toute façon.
Oui, Enqueuconditionnel doit être utilisé pour faire un test vraiment attendre pour un événement. Je suppose que j'ai fait mon exemple un peu trop trivial, mes excuses. Il utilise désormais enQuiqueural pour attendre sur l'état booléen de premier planchedchanged pour se tourner vers true.
Voici comment j'ai fait cela dans le passé (j'ai utilisé Nunit, il peut donc être un peu différent): a le bon effet secondaire de pouvoir déboguer et travaillez ce qui a changé, si ce n'était pas le nom prénom . Vraiment pratique lorsque vous avez plusieurs champs calculés à partir d'autres champs. Vous pouvez également consulter l'autre aspect du comportement dans votre code:
Peut-être qu'il y a plus de contexte à ce code qui n'est pas révélé, mais ce que je vois semble inutilement compliqué. Pourquoi déranger l'accrochage dans l'événement CODE> SUPPROPERTYCHANGED code> du tout? Vérifiez simplement la propriété après la définition.
[TestMethod]
[Tag("Property")]
public void FirstNameTest()
{
var expected = "John";
var sut = new CustomerViewModel();
sut.Firstname = expected;
Assert.AreEqual(expected, sut.Firstname);
}
Ce serait quelque peu inutile. Pourquoi l'actif que le cadre est capable de traiter correctement la sécheuse d'une autoproperty? Le test commence à donner un sens au moment où vous souhaitez vérifier que les événements de propriété sont soulevés comme prévu. que est la seule chose qui mérite d'aller de la valeur dans un tel test.
@Martin, je conviendrais que le test de la sécheuse d'une autoproperty ne fournirait aucun avantage. Toutefois, si vous regardez le code d'origine (posté par Hooman), vous remarquerez que la propriété est définie que si la valeur entrante n'est pas égale à la valeur de _Contact.firstName. C'est la partie du code avec lequel mon test refacturé est concerné.
Vous ne devriez pas placer des revendeurs dans une Lambda. Affirme jeter des exceptions quand ils échouent. Si vous faites cela dans les Lambdas, ceux-ci vont enfoncer à l'intérieur du sous-test d'objet et vous courez le risque de ceux qui sont traités par l'objet. Vous devriez plutôt attribuer des résultats à certaines variables (généralement bool) à partir de la portée du test, puis affirmez par rapport à ceux lorsque vous êtes retourné et déroulé de la pile d'appel.