Grail находится на уровень ниже xUnit-библиотеки, поэтому с DDT конфликтов не возникает. Мы используем эту библиотеку вместе с nose: http://ddt.readthedocs.org/en/latest/
Идея в том, чтобы не использовать «таблички», Gherkin, excel-файлы и прочее, а писать код. В этом основное отличие от других инструметов в Python-мире, решающих ту же задачу.
Про 100% уверенность более чем согласен, немногие из нас делают софт для атомных электростанций.
В сложных проектах между отдельными модулями иногда бывают не тривиальные связи — например, ошибка возникает в модуле 3, при специфических параметров в модулях 2 и 7.
Наступили на больной мозоль. Если нам надо перебрать варианты работы модуля 3, то модули 2 и 7 не только не нужны, но будут только мешать. Сэмулировать ответ от 2 и 7 гораздо проще с заглушек, чем довести 2 и 7 до того состояния, при котором они самостоятельно нужным образом дёрнут модуль 3.
Если стоит задача протестировать модуль 3, то гораздо проще и дешевле во всех смыслах (время выполнения, время на разработку автотеста) сделать это в изоляции от 2 и 7. Немного больше информации по этому поводу — Test Double Pattern
Получаем своеобразное тестирование по методу Монте-Карло.
Эта штука работает. Знаю несколько удачных случаев, где подобный подход принёс хорошие результаты.
Я бы посоветовал критично взглянуть на свою текущую деятельность: всегда есть места, что улучшать и оптимизировать. И чаще всего это те проблемы, которые непонятно, как решать.
Бывает, для «просветления» нужно сходить в отпуск или съездить на профильную или смежную по тематике конференцию.
Подход не универсален, согласен на 100%.
Случай достаточно уникален, так как редко такое удаётся провернуть. В виду итересности случая он и был упомянут в докладе.
Но в докладе я лишь бегло прошёлся по этой теме в виду банального ограничения по времени.
Конечно, функциональные тесты не реиспользовались «в лоб» в нагрузочных. Мы строили нагрузочные сценарии из тех же «кирпичей», из которых строились функциональные тесты.
Тот же разбор логов и ресурсоёмкие тестовые файловые манипуляции не паралелились.
Там было много подводных камней. Пришлось достаточно просидеть за профайлером, так как в самих тестах были местами критические секции, которые выполнялись лишь в одном потоке.
Были сделаны определённые допущения исходя из знаний Siebel'a. Нам было важно реалистично нагрузить базу, так как для Siebel'a чаще всего она узкое место. Поэтому мы в некотором роде пренебрегли реалистичностью нагрузки на web-сервер.
В общем, нужен был результат и его достигли, затратив на это меньше, чем если бы мы писали отдельные тесты на LoadRunner'e.
Вспоминается первая заповедь перфекциониста-прокрастинатора: «Лучше сделать хорошо, но никогда, чем кое-как и сегодня»
На самом деле задача не становится «эффективно решаема», а становится другая задача.
Задача другая, но суть в том, что она эквивалентна первой. Вместо большого сценария мы пишем много маленьких. Кажется, что их много, но по факту в долгосрочной перспективе их нужно меньше, чем если бы тестировать то же самое end-to-end тестами.
Плюс мы можем выбросить те вещи, которые заведомо нам не интересно тестировать. Например, third-party вещи, с которыми нам нужно протестировать только совместимость.
То же самое и в случае перехода с тестов в браузере на тесты через веб-сёрвисы. Это не упрощённое решение задачи — это другая, более простая задача.
Тут аналогично. Если перестать тестировать в браузере, а тестировать только веб-сервисы, то мы потеряем покрытие, полностью согласен. Но если мы покроем тестами отдельно back-end, отдельно front-end, а затем посмотрим их интеграцию, то суммарный результат будет лучше, чем если мы будем все автотесты писать для системы целиком.
На моём проекте, о котором я рассказывал, вёрстка была коробочной, поэтому отдельно front-end не имело особого смысла тестировать.
«Ловкость рук и никакого мошеничества...»
Я ни в коей мере не стараюсь обмануть аудиторию. Я рассказывал про общепринятые подходы, которые принесли реальную пользу на проекте, где мне посчастливилось поработать.
Наступили на больной мозоль. Если нам надо перебрать варианты работы модуля 3, то модули 2 и 7 не только не нужны, но будут только мешать. Сэмулировать ответ от 2 и 7 гораздо проще с заглушек, чем довести 2 и 7 до того состояния, при котором они самостоятельно нужным образом дёрнут модуль 3.
Если стоит задача протестировать модуль 3, то гораздо проще и дешевле во всех смыслах (время выполнения, время на разработку автотеста) сделать это в изоляции от 2 и 7.
Немного больше информации по этому поводу — Test Double Pattern
Эта штука работает. Знаю несколько удачных случаев, где подобный подход принёс хорошие результаты.
Бывает, для «просветления» нужно сходить в отпуск или съездить на профильную или смежную по тематике конференцию.
Случай достаточно уникален, так как редко такое удаётся провернуть. В виду итересности случая он и был упомянут в докладе.
Но в докладе я лишь бегло прошёлся по этой теме в виду банального ограничения по времени.
Конечно, функциональные тесты не реиспользовались «в лоб» в нагрузочных. Мы строили нагрузочные сценарии из тех же «кирпичей», из которых строились функциональные тесты.
Тот же разбор логов и ресурсоёмкие тестовые файловые манипуляции не паралелились.
Там было много подводных камней. Пришлось достаточно просидеть за профайлером, так как в самих тестах были местами критические секции, которые выполнялись лишь в одном потоке.
Были сделаны определённые допущения исходя из знаний Siebel'a. Нам было важно реалистично нагрузить базу, так как для Siebel'a чаще всего она узкое место. Поэтому мы в некотором роде пренебрегли реалистичностью нагрузки на web-сервер.
В общем, нужен был результат и его достигли, затратив на это меньше, чем если бы мы писали отдельные тесты на LoadRunner'e.
Вспоминается первая заповедь перфекциониста-прокрастинатора: «Лучше сделать хорошо, но никогда, чем кое-как и сегодня»
Задача другая, но суть в том, что она эквивалентна первой. Вместо большого сценария мы пишем много маленьких. Кажется, что их много, но по факту в долгосрочной перспективе их нужно меньше, чем если бы тестировать то же самое end-to-end тестами.
Плюс мы можем выбросить те вещи, которые заведомо нам не интересно тестировать. Например, third-party вещи, с которыми нам нужно протестировать только совместимость.
Тут аналогично. Если перестать тестировать в браузере, а тестировать только веб-сервисы, то мы потеряем покрытие, полностью согласен. Но если мы покроем тестами отдельно back-end, отдельно front-end, а затем посмотрим их интеграцию, то суммарный результат будет лучше, чем если мы будем все автотесты писать для системы целиком.
На моём проекте, о котором я рассказывал, вёрстка была коробочной, поэтому отдельно front-end не имело особого смысла тестировать.
Я ни в коей мере не стараюсь обмануть аудиторию. Я рассказывал про общепринятые подходы, которые принесли реальную пользу на проекте, где мне посчастливилось поработать.
Несколько пруф-ссылок:
Те же мысли другими словами от Мартина Фаулера
Доклад с Selenium-конференции, в котором говорят о том, что не надо всё покрывать всё end-to-end тестами через Selenium