Юнит тесты для MVVM архитектуры

Столкнулся с такой проблемой: есть несколько абстрактных базовых классов вьюмоделей (для простого объекта, коллекции и дерева). У них один общий базовый класс ViewModel. Вьюмодели поддерживают отмену/сохранение/обновление своих данных. При использовании в коде можно создавать целые графы зависимостей одних вьюмоделей от других, т.е., например, на форме есть дерево, каждый элемент дерева содержит список элементов, которые при выборе узла дерева отображаются в определенном месте формы, каждый элемент этой коллекции может состоять из набора различных достаточно больших объектов (для которых нужны свои вьюмодели), в зависимости от типа.
Начал писать тесты для базовых вьюмоделей и столкнулся с такой проблемой, что мои тесты очень простые и всегда проходят, но для каких-нибудь сложных сценариев взаимодействия между вьюмоделями могут возникать ошибки (не все изменения в графе отменились, где-то упало и часть изменений отменить потом не удается, сохранение в некоторых случаях записывает не все данные в базу и т.д.).
Как правильно писать тесты нигде не нашел. Везде рекомендации общего плана, типа тестируйте одно действие за один раз, а что делать, если к ошибке может привести не каждое действие в отдельности, а их комбинация?

0

Сообщение от SharpProg а что делать, если к ошибке может привести не каждое действие в отдельности, а их комбинация?

вас интересует mock.

http://artlang.net/article/view/14/

0

Не очень понял как mock помогает решить эту проблему.
Допустим в моей вьюмодели есть свойство IsEmpty, которое проверяет, что все её свойства заполнены значениями по умолчанию. Тогда:
1) если мы изменяем какое-нибудь свойство - IsEmpty == false;
2) если изменяем какое-нибудь свойство и делаем отмену - IsEmpty == true;
3) если изменяем какое-нибудь свойство и сохраняем - IsEmpty == true;
4) если изменяем какое-нибудь свойство, сохраняем и пробуем отменить - IsEmpty == false;
5) если изменяем какое-нибудь свойство и обновляем вьюмодель - IsEmpty == true;

Это простой пример. Угадать все цепочки возможных действий нереально. Но уже видно, что отмена во втором случае и в четвертом приводит к разному значению IsEmpty.

Теперь придуманный пример: есть некоторая реализация списка на основе массива.
1) Тестируем добавление элемента - тест проходит.
2) Тестируем удаление элемента - тест проходит.

В релизе программы встретился код: list.Add(item); list.Remove(item); list.Add(item); - программа упала (хотя тесты проходили). При отладке выяснилось, что в методе удаления не происходил декремент индекса и последующий Add привел к выходу индекса за границы массива. Это грубый пример и такая ошибка скорее всего не доживет до продакшена, но он демонстрирует, что простая невнимательность может привести к подобным неочевидным ошибкам, хотя тесты будут успешно проходить. Однако, данная ошибка не произойдет, если Add добавляет элемент, но в массиве еще достаточно места: list.Add(item); list.Remove(item); list.Add(item); - сработает, но в массиве будет "дырка" вместо элемента, которая может спровоцировать совсем другие ошибки.

Возможно я еще не разобрался как правильно писать тесты, но хочу это сделать.

0

Сообщение от SharpProg Теперь придуманный пример: есть некоторая реализация списка на основе массива. 1) Тестируем добавление элемента - тест проходит. 2) Тестируем удаление элемента - тест проходит.

Тест должен не просто вызывать метод, а вызывать метод и проверять состояние объекта после вызова метода.
То есть, нам недостаточно того, чтобы метод Сложение отработал без ошибок - нам нужно ещё, чтобы он правильную сумму вернул.

0

Сообщение от Shamil1 Тест должен не просто вызывать метод, а вызывать метод и проверять состояние объекта после вызова метода. То есть, нам недостаточно того, чтобы метод Сложение отработал без ошибок - нам нужно ещё, чтобы он правильную сумму вернул.

Метод Add ничего не возвращает. Мы можем лишь получить добавленный элемент по индексу. Тут всё в порядке.
Метод Remove возвращает true, если элемент был удален. Мы можем проверить отсутствие элемента с помощью метода Contains. Тут тоже всё в порядке. Однако программа упадет, т.к. нет декремента индекса у внутреннего массива.

0

Сообщение от SharpProg Метод Add ничего не возвращает.

Метод Add меняет состояние объекта. Тест должен проверить, правильно ли поменялось состояние объекта.

Добавлено через 58 секунд
Это общий недостаток "объектов с состоянием". Чем меньше у вас таких объектов, тем проще и надёжней программы.

0