Должен ли я выполнить юнит-тестирование моего представления в MVP (или VM) или как сохранить код в представлении до минимума? - PullRequest
3 голосов
/ 01 сентября 2009

Я использую Model-View-Presentation Model в своем приложении, и мне интересно, нужно ли мне создавать модульные тесты для представления. (Я на .net 2.0 WinForms)

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

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

Другое дело, иногда мне кажется, что более эффективно работать с самим элементом управления, чем с PM, и привязка данных отражает изменение обратно к элементу управления. Например, у меня есть сетка данных, и, скажем, я переместил строку из индекса 5 в 3. Я могу вызвать метод в PM, и сетка отражает изменение с помощью привязки данных. Или я могу просто сделать это на контроле. Разница в том, что первый метод заставляет элемент управления восстанавливать себя с нуля, а второй - нет.

Что ты переживаешь?

Ответы [ 3 ]

4 голосов
/ 12 сентября 2009

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

И если вы действительно хотите покрыть представления тестами, вы все равно можете использовать некоторые среды тестирования графического интерфейса WinForms, такие как White (хотя такое тестирование намного сложнее и дороже, чем просто написание модульных тестов с имитациями).

Вот хороший источник информации о WinForms, MVP и модульном тестировании: Presenter First: организация сложных приложений с графическим интерфейсом для тестовой разработки

3 голосов
/ 01 сентября 2009

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

Трагически логика может иногда попадать в поле зрения. Хороший способ избежать этого - написать функциональные тесты, используя что-то вроде Fitnesse (да, есть версия .NET). Fitnesse предназначен для тестирования приложения на протяжении всего пути, в качестве альтернативного пользовательского интерфейса, и когда все сделано правильно, людям трудно что-то представить.

Вы также можете выполнять такие тесты в рамках модульного тестирования, но я считаю, что разделение полезно, плюс деловые люди могут помочь в написании и запуске тестов (потому что они в вики-формате).

0 голосов
/ 11 октября 2009

Я думаю, что вы на правильном пути, не допуская бизнес-логики в поле зрения. Тем не менее, я не вижу ничего плохого в логике представления в View.

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

На мой взгляд, юнит-тесты для невизуальных классов чрезвычайно полезны. Существует также ценность в написании пользовательских приемочных, функциональных и / или интеграционных тестов, которые охватывают взаимодействие всей или части системы; инструменты, такие как FitNesse (как упомянуто ryber) предназначены для них. Наконец, есть тестирование GUI; хотя автоматизация этого для веб-сайтов может принести некоторую пользу, я считаю, что затраты на обслуживание тестирования перевешивают преимущества, когда речь идет о WinForms.

Однако я не эксперт. Я определенно рекомендую изучить, что тестеры (а не маркетологи) говорят о тестировании графического интерфейса, и примите решение сами.

...