Собственно зачем оно вообще нужно?
Для того чтобы было проще поддерживать ваши красивые автоматизированные тестики.
Цели (как завещала Элизабет Хэндриксон):
- Задать формат для описания тестов (тестовые базы, эксельки, текстовые файлики и прочая бла бла бла)
- Задать формат для общения с тестируемым приложением (собственно инструменты тестирования - Selenium, WatiR, JMeter, HQ QTP и прочая бла бла бла)
- Запускать тесты
- Получать результаты
Более или менее стандартные подходы, озвученные лет так семь назад, позволяют нам получить довольно разный уровень абстракции (бери и жри что нравится!). Вплоть до того, что для написания автоматических тестов не нужно будет писать код вообще. То есть какое-то базовое понимание происходящего иметь нужно будет, но не более того. Для расширения возможностей и фиксов да, нужно будет писать код, но для этого понадобится существенно меньше людей. С другой стороны дизайном тестов человеку занимающемуся расширением фреймворка тоже заниматься не нужно. И любой из вариантов будет в сотни раз лучше и гибче record/playback, при этом не сильно сложнее для конечного пользователя.
А что же вижу я?
Обычно я вижу что у нас садят человека писать именно тесты. Кодить, блджад. Каждый отдельно взятый тест кодить. И это вместо того чтобы создать нормальную среду для того чтобы абстрагироваться от конкретно процесса написания кода и перейти к тестовым сценариям и просто тест кейсам.
Придумыванием этого занимаются люди поедающие собак на тест менеджменте. То есть люди занимающиеся процессом оптимизации трудозатрат тупо просирают ресурсы. И ладно бы так...
Вторая проблема (вытекающая из первой) в том, что в том что я обычно вижу вокруг сами тесты порой довольно сложно отделить от окружения, вспомогательных библиотек и whatever you use.
И ведь можно сделать все чтобы интегрироваться в TCM и прочий bug tracker безболезненно, но... who cares? Сначала всех хочется с разбегу долбануться лбом об стену, а потом уже думать как же ее обойти.
была мысль создать такую архитектуру в которой можно было бы писать кейсы иксмльками абстрагируясь от кода, но встаёт вопрос о том как объяснить менеджеру что это надо ?
ОтветитьУдалитьи надо ли ? чем по вашему мнению писать тесты кодом плохо ? :)
Зачем Вам создавать свое? Возьмите FitNesse или RSpec и пользуйтесь.
ОтветитьУдалитьНу как объяснить менеджеру совсем другой вопрос. И мне им пока заниматься не нужно. Да и в общем-то не всегда нужно сильно упрощать. У нас сейчас почти весь фреймворк это модули/библиотеки (ну для частных случаев еще базы если массив входных данных большой). У такого подхода минус в том что пользователю фреймворка нужно определенную квалификацию, но у нас пока такой проблемы нет вообще.
ОтветитьУдалитьА писать свое нужно часто потому что существующие решения не подходят по тем или иным причинам. FitNesse или RSpec покрывают далеко не все потребности которые требуются для автоматизированного фреймворка.