Unité testant le Viewmodel

Question

Je suis un peu nouveau pour TDD. J'ai commencé à créer les propriétés dont j'ai besoin sur le modèle de vue en tant que propriété auto.

public string Firstname { get; set; } 

Je crée ensuite un test

[TestMethod] 
[Tag("Property")] 
public void FirstNameTest() 
{ 
    ViewModel = new CustomerViewModel(); 
    ViewModel.PropertyChanged += (s, e) => 
            { 
             Assert.AreEqual("Firstname", e.PropertyName); 
             Assert.AreEqual("Test", ViewModel.Firstname); 
            }; 
    ViewModel.Firstname = "Test"; 
} 

Alors je prolonger la mise en œuvre effective de faire le test passe comme ceci:

public string Firstname 
{ 
    get { return _contact.FirstName; } 
    set 
    { 
     if (_contact.FirstName == value) 
      return; 

     _contact.FirstName = value; 

     RaisePropertyChanged(() => Firstname); 
    } 
} 

Le problème que j'ai est ce test passe encore pour la propriété Aut. Un conseil pour moi comment je pourrais améliorer mon processus?

Answer 1

Vous pouvez essayer d'écrire le test pour être asynchrone. Considérez cette méthode de test:

[TestMethod] 
[Asynchronous] 
public void TestMethod1() 
{ 
    TestViewModel testViewModel = new TestViewModel(); 

    bool firstNameChanged = false; 

    testViewModel.PropertyChanged += 
     (s, e) => 
      { 
       if (e.PropertyName == "FirstName") 
       { 
        firstNameChanged = true; 
       } 
      }; 

    EnqueueCallback(() => testViewModel.FirstName = "first name"); 
    EnqueueConditional(() => firstNameChanged == true); 
    EnqueueTestComplete(); 
} 

Notez l'attribut Asynchrone en haut de la méthode. Il y a deux méthodes importantes ici: EnqueueCallback et EnqueueTestComplete. EnqueueCallback ajoutera des expressions lambda à une file d'attente et la méthode de test attendra que le rappel en cours soit exécuté. Dans le cas présent, nous nous abonnons à l'événement PropertyChanged sur ViewModel et nous définissons une variable booléenne locale sur true lorsque la propriété FirstName notifie une modification. Nous avons ensuite mis en file d'attente deux rappels: l'un pour définir la propriété FirstName et l'autre pour affirmer que la variable booléenne locale a changé de valeur. Enfin, nous devons ajouter un appel à EnqueueTestComplete() afin que le framework sache que le test est terminé. REMARQUE: Pour obtenir EnqueueCallback et EnqueueTestComplete, vous devez hériter de SilverlightTest sur votre classe de test. Vous devez également importer Microsoft.Silverlight.Testing pour obtenir l'attribut Asynchronous. Il devrait ressembler à ceci:

using Microsoft.Silverlight.Testing; 
using Microsoft.VisualStudio.TestTools.UnitTesting; 

namespace Foo.Example.Test 
{ 
    [TestClass] 
    public class Tests : SilverlightTest 
    { 

     // ... tests go here 
    } 
} 

Answer 2

Vous devez avoir un autre test qui affirme réellement que votre PropertyChanged se déclenche. Lorsque vous effectuez ce test, votre propriété auto doit échouer, car l'événement ne se déclenchera jamais.

Here's an example of how to do that in Moq

Answer 3

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); 
    } 

Answer 4

Un test devrait échouer à moins que le comportement est le test est déjà mis en œuvre.

Pour tester les notifications de modification de la propriété dans ma dernière tentative, j'ai créé a helper class qui m'a aidé à écrire des tests comme celui-ci (il est dans NUnit)

[Test] 
public void NotifiesChangeIn_TogglePauseTooltip() 
{ 
    var listener = new PropertyChangeListener(_mainViewModel); 

    _mainViewModel.TogglePauseCommand.Execute(null); 

    Assert.That(listener.HasReceivedChangeNotificationFor("TogglePauseTooltip")); 
} 

Answer 5

Voilà comment je l'ai fait dans le passé (je l'ai utilisé NUnit il est peut-être un peu différent):

[Test] 
public void ShouldNotifyListenersWhenFirstNameChanges() 
{ 
    var propertiesChanged = new List<string>(); 

    ViewModel = new CustomerViewModel(); 
    ViewModel.PropertyChanged += (s, e) => propertiesChanged.Add(e.PropertyName); 

    ViewModel.Firstname = "Test"; 

    Assert.Contains("Firstname", propertiesChanged);  
    Assert.AreEqual("Test", ViewModel.Firstname); 
} 

a le beau côté -effect d'être en mesure de déboguer et de travailler sur ce qui a changé, si ce n'était pas le Firstname. Très pratique lorsque vous avez plusieurs champs calculés à partir d'autres champs.Vous pouvez également regarder l'autre aspect du comportement dans votre code:

[Test] 
public void ShouldNotNotifyListenersWhenPropertiesAreNotChanged() 
{ 
    var propertiesChanged = new List<string>(); 

    ViewModel = new CustomerViewModel(); 
    ViewModel.Firstname = "Test"; 

    ViewModel.PropertyChanged += (s, e) => propertiesChanged.Add(e.PropertyName); 

    ViewModel.Firstname = "Test"; 

    Assert.AreEqual(0, propertiesChanged.Count); 
} 

Answer 6

Peut-être il y a plus d'arrière-plan à ce code qui n'est pas révélé, mais ce que je vois semble inutilement compliqué. Pourquoi s'embêter avec l'événement RaisePropertyChanged? Vérifiez simplement la propriété après l'avoir définie.

[TestMethod] 
[Tag("Property")] 
public void FirstNameTest() 
{ 
    var expected = "John"; 
    var sut = new CustomerViewModel(); 

    sut.Firstname = expected; 

    Assert.AreEqual(expected, sut.Firstname); 
} 

Cela transforme également le test en un véritable test unitaire.