Jednostka testująca Viewmodel

Question

Jestem trochę nowa w TDD. Zacząłem tworzyć właściwości, których potrzebuję w modelu widoku, jako zwykłą właściwość auto.

public string Firstname { get; set; } 

Następnie tworzę 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"; 
} 

Następnie chciałbym przedłużyć faktyczną realizację zrobić testy przechodzą tak:

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

     _contact.FirstName = value; 

     RaisePropertyChanged(() => Firstname); 
    } 
} 

Mam problem jest, że próba nadal przechodzi dla właściwości Aut. Jakaś wskazówka dla mnie, jak mogę poprawić mój proces?

Answer 1

można spróbować pisania testu być asynchroniczny. Rozważ tę metodę testu:

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

Zauważ asynchroniczny atrybut u góry metody. Istnieją dwie ważne metody: EnqueueCallback i EnqueueTestComplete. EnqueueCallback doda wyrażenia lambda do kolejki, a metoda testowa będzie czekać, aż bieżące wywołanie zwrotne zostanie wykonane. W tym przypadku subskrybujemy zdarzenie PropertyChanged w narzędziu ViewModel i ustawiamy lokalną zmienną binarną na wartość true, gdy właściwość FirstName powiadamia o zmianie. Następnie dodajemy dwa wywołania zwrotne: jeden do ustawienia właściwości FirstName i jeden do potwierdzenia, że ​​lokalna zmienna binarna zmieniła wartość. Na koniec musimy dodać wywołanie metody EnqueueTestComplete(), aby framework wiedział, że test się skończył.

UWAGA: Aby uzyskać EnqueueCallback i EnqueueTestComplete, musisz dziedziczyć z SilverlightTest na swojej klasie testowej. Musisz również zaimportować Microsoft.Silverlight.Testing, aby uzyskać atrybut asynchroniczny. Powinno to wyglądać mniej więcej tak:

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

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

     // ... tests go here 
    } 
} 

Answer 2

Musisz mieć inny test, który faktycznie zapewnia, że ​​Twój PropertyChanged nawet strzela.

Po wykonaniu tego testu własność automatyczna powinna się nie udać, ponieważ zdarzenie nigdy się nie uruchomi.

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

Answer 3

można zrobić coś takiego:

[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

test nie powiedzie się, chyba że zachowanie to jest testowanie jest już realizowany.

Do testowania powiadomienia o zmianach nieruchomość w mojej ostatniej próbie, stworzyłem a helper class że pomógł mi napisać testy tak (To w NUnit)

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

    _mainViewModel.TogglePauseCommand.Execute(null); 

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

Answer 5

Oto jak robiłem to w przeszłości (Użyłem NUnit więc może być nieco inny):

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

Posiada piękny bok -możliwość debugowania i sprawdzenia, co się zmieniło, jeśli nie było to Firstname. Naprawdę przydatne, gdy oblicza się wiele pól z innych pól.Można również spojrzeć na inne aspekty zachowań w kodzie:

[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

Może jest bardziej tło do tego kodu, który nie jest objawione, ale to, co widzę wydaje się niepotrzebnie skomplikowane. Po co zawracać sobie głowę w ogóle wydarzeniem RaisePropertyChanged? Po prostu sprawdź właściwość po jej ustawieniu.

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

    sut.Firstname = expected; 

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

To również zmienia test w prawdziwy test jednostkowy.