WPF MVVM - module Testing team - private and public methods?

Basically, if I use MVVM and expose public ICommands, should my delegates be public or private?

+7
source share
3 answers

I would make them private - they are not part of your public interface class, which is for the public properties of ICommand.

+11
source

Personally, I would go with private methods, and I will tell you why. You open ICommand , which, it seems to me, should call CanExecute before calling Execute. If they do not, they go against the API and shoot in the leg, and at this moment it is not in your hands. Just as if someone used reflection to set an important private variable to zero and broke your class design because of this ... shot in the foot. So why make members private? Since there is no need to expose elements that should not be called directly.


Basically, when you unit test members that you don't do individually, you do this the way the API intends to perform member actions. This way, you are not actually testing the participants, but in addition you are testing the team, which again means that they must be tested in pairs in a certain order:

 if (CanExecute) { Execute; } 
+4
source

I have MVVM for easy control of the increase, decrease, and slider buttons.

If you have the ICommand and INotifyPropertyChanged tests, you can make UnitTest look:

 [TestMethod] public void TestViewModel3() { int min = -10; int max = 10000; int initVal = 50; bool initState = false; ToglledSliderModel model = new ToglledSliderModel(initState, initVal, min, max); ToglledSliderViewModel viewModel = new ToglledSliderViewModel(); viewModel.Model = model; int status = 567; viewModel.PropertyChanged += delegate { status = 234; }; for (int i = 1; i < 100; i++) { status = 567; ICommand ic = viewModel.IncreaseValue; ic.Execute(this); Thread.Sleep(2); Assert.AreEqual(status, 234); Assert.AreEqual(model.SliderValue, initVal + i); } } 

you can see i check the behavior of INotifyPropertyChanged and the execution of ICommand

+2
source

All Articles