Пару дней назад провел очередной тренинг по Test Driven Development, на этот раз открытый и в Москве.
По уровню восприятия нового подхода ребята оказались на высоте, то ли были морально подготовлены, то ли я стал лучше рассказывать :)
Практика прошла на отлично, сначала как обычно было трудно думать в терминах тестов, а не интерфейсов и поведения классов, но этот этап прошел удивительно легко и быстро.
Уже второй раз задают вопрос про Test Driven, да и вообще модульного тестирования пользовательского интерфейса.
Вообще если брать термин "модульный тест" и прикладывать его к UI, то получим тест интеграционный, т.е. который тестирует цепочку вызовов да еще и не изолирован от внешних ресурсов, например базы данных. Различные инструменты для UI тестирования (selenium, watin) используют фреймворки модульного тестирования, вроде xunit, но все же на мой взгляд такими тестами должны (в основном) заниматься тестировщики.
Что касается Test Driven UI, то здесь по опыту приходит на ум только один инструмент - FIT, в котором можно сначала описать простым английским как будет выполняться тест, а уже потом идти создавать саму программу, ее UI и дальше просто связывать интерфейс пользователя с написанными ранее сценариями и запускать. Правда, понадобятся дополнительные фикстуры, но их и самим можно написать.
Следующий тренинг в середине июля в Питере, после занятий сразу на ролики!
среда, 24 июня 2009 г.
TDD в Москве
Подписаться на:
Комментарии к сообщению (Atom)
4 коммент.:
Если использовать подходы семейства MVC/MVP/MVVM/и_прочая, то UI у нас должен получиться совсем лёгкий/тонкий. Как правило, остаются, в основном, только обработчики событий. Их можно сделать protected и вызывать в классах-наследниках, специально создаваемых (или даже автоматически генерируемых), например, в тестовой сборке (если говорить о .NET).
Такой способ
1) очень прост и понятен
2) почти не имеет ограничений
3) способствует покрытию вплоть до 100%
Хорошая идея, тогда реальные контролы нужно подменять на фейковые, верно? Прельщает то, что можно очень сильно автоматизировать процесс создания таких тестов.
Однако, у тестов через "прокликивание" на мой взгляд все-таки больше вероятность найти баг (например, кнопка или ссылка вообще не отображаются на форме), но они и существенно дороже..
> тогда реальные контролы нужно подменять на фейковые, верно?
нет, в этом нет необходимости совсем
> Однако, у тестов через "прокликивание" на мой взгляд все-таки больше вероятность найти баг (например, кнопка или ссылка вообще не отображаются на форме)
Если прокликивать то, что осталось непокрыто ПОСЛЕ юнит-тестирования, то, думаю, вероятность МЕНЬШЕ :))
Небольшое дополнение по поводу:
"Вообще если брать термин "модульный тест" и прикладывать его к UI, то получим тест интеграционный, т.е. который тестирует цепочку вызовов да еще и не изолирован от внешних ресурсов, например базы данных."
Мне кажется, что тут все зависит от уровня абстракции. Если рассматривать свой тест как тест цепочки событий, то это интеграционный тест, если все приложение рассматривать целиком как черный ящик (не разделяя на БД и т.д.), то это модуль, и значит тестирование - модульное.
Отправить комментарий