В MVVM с WPF, как делают меня модульный тест ссылка между ViewModel и Представлением

Question

В MVVM с WPF, как делают меня модульный тест ссылка между ViewModel и Представлением

В MVVM нормально подключить Представление к ViewModel с привязкой данных.

Поэтому, если название свойства изменяются на одном из Объектов модели, который связан с данными к нет никакой ошибки компилятора.

Когда компилятор не остановит ошибку, следующей вещью, о которой я думаю, является “UnitTest”, Однако

Как делают Вас модульный тест это, не тратя навсегда запись теста GUI?

Существует ли система, которая проверит, что все свойства, которые связываются с, допустимы, (не имея необходимость выполнять UI), что я могу звонить в модульный тест?

Я ищу что-то, что получит представление и затем цикл по всем средствам управления WPF, для каждого управления WPF, это посмотрит на всю привязку и проверит, допустимы ли они.

Между прочим было несколько хороших вопросов о том, как сделать OnPropertyChanged безопасным, и/или как протестировать его (Но сделанный их переходят к уровню представления WPF.)

Я поместил щедрость на этот вопрос, как кто-то, должно быть, думал трудно о проблеме и придумал soltions.

20

wpf unit-testing model-view-controller mvvm

задан Community 23 May 2017 в 12:13

2 ответа

Другие вопросы по тегам:

wpf unit-testing model-view-controller mvvm

Похожие вопросы:

score 3 · Answer 1

Действительно хороший вопрос. Проголосовал. Я тоже хотел бы знать ответ.

Один из известных мне передовых методов (, предложенный Джошем Смитом , спасибо Гишу за указание на это) - наличие класса модели базового представления для проверки в методе OnPropertyChanged () , действительно ли собственность действительно существует. Например: [

abstract class ViewModelBase
{
    [Conditional("DEBUG")]
    public void VerifyPropertyName(string propertyName)
    {
        // Verify that the property name matches a real,  
        // public, instance property on this object.
        if (TypeDescriptor.GetProperties(this)[propertyName] == null)
        {
            if (this.ThrowOnInvalidPropertyName)
                throw new ArgumentException(propertyName);

            string msg = "Invalid property name: " + propertyName;
            Debug.Fail(msg);
        }
    }

    protected void OnPropertyChanged(string propertyName)
    {
        VerifyPropertyName(propertyName);

        PropertyChangedEventHandler handler = this.PropertyChanged;
        if (handler != null)
        {
            var e = new PropertyChangedEventArgs(propertyName);
            handler(this, e);
        }
    }
}

] Но это не поможет вам найти проблемы с орфографией в XAML. Хм ... Я не знаю существующего решения для этого. Может быть, ребята из WPF Disciples что-нибудь подскажут. Думаю, я бы пошел с PresentationTraceSources.DataBindingSource и добавил в его коллекцию Listners экземпляр TextWriterTraceListener , а затем отслеживал вывод. Как только мы получаем ошибку или предупреждение на нашем радаре, мы должны не пройти тест.

Нашел хороший пример: WPF Snippet - Detecting Binding Errors

Надеюсь, это поможет. Хотя бы немного :).

Ура, Анвака.

score 0 · Answer 2

Как указывает Анвака, использование базового класса для вашей модели представления, который проверяет имена свойств, может помочь избежать этой конкретной проблемы (хотя он не сообщит вам, когда ваш класс виртуальной машины отправляет собственное уведомление об изменении свойства и игнорирует метод в базовый класс, не то чтобы я когда-либо видел что-либо подобное в моем коде).

И вы можете (и должны) настроить свой код так, чтобы вещи, которые не работают, выходили из строя так, как вам было видно. Парадоксально в этом то, что если вы знаете, какие вещи могут потерпеть неудачу, и вы наблюдаете за ними, они этого не делают, потому что тот факт, что вы наблюдаете за ними, удерживает вас от совершения ошибок, которые приводят их к неудачам (например, написание селектора шаблонов, который не всегда возвращает шаблон).

Но по сути, представление - это пользовательский интерфейс, поэтому я был бы очень удивлен, если бы нашел методы его тестирования, которые не были также методами тестирования пользовательского интерфейса.