Comments 29
Я так и не понял, какую проблему решает это инструмент, которую бы не решали VCS.
Проблема, как понимаю ее я:
— есть файл с тестом.
— есть глобальный рефакторинг, который меняет валидное поведение
— куча тестов падает, потому что расчитывали на другое «валдиное» поведение.
Стандартное решение:
— прогнать весь набор файлов.
— проанализировать.
— все, которые упали из-за рефакторинга — поправить; или откатить рефакторинг.
Так? Какую проблему решает этот инструмент лучше, чем VCS?
Проблема, как понимаю ее я:
— есть файл с тестом.
— есть глобальный рефакторинг, который меняет валидное поведение
— куча тестов падает, потому что расчитывали на другое «валдиное» поведение.
Стандартное решение:
— прогнать весь набор файлов.
— проанализировать.
— все, которые упали из-за рефакторинга — поправить; или откатить рефакторинг.
Так? Какую проблему решает этот инструмент лучше, чем VCS?
существуют и альтернативные варианты решения проблемы, например, инспекции кода и использование инструментов в репозиториях (например, GIT, SVN). Однако инспекции бесполезны в случае внесения автоматических изменений в сотни тестов, а отслеживание изменений в коде с помощью инструментов репозитория после нескольких мержей — процесс трудоемкий и долгий.
В действительности:
— есть наборы с сотнями тестов, которые написали и забыли,
— есть необходимость периодического рефакторинга тестовой системы, при котором не должны вноситься изменения в логику тестов, но тем не менее, иногда вносятся.
— проверять «все, которые упали из-за рефакторинга — поправить; или откатить рефакторинг» — не вариант, т.к. замечают изменения в логике тестов не сразу, а когда замечают, искать изменённые кусочки кода в git-е – долго.
Один раз было потрачено несколько часов, только для того, чтобы восстановить логику работы и код всего восьми тестов, потому что было сделано уже множество мержей поверх. Кроме того, забывается, как именно должны работать эти тесты. Сейчас, в ситуациях с изменением кода множества тестовых функций, достаточно скопировать их целиком из ревизии, и не мучаться с поисками всех мержей.
Ну, во-первых, Continuous Integration — если падение тестов «заметили не сразу», не понятно, зачем они вообще нужны.
Во-вторых, есть история изменений файла. По ней погулять — тоже не составит проблемы.
В-третьих, если мы «просто откатимся» на древнюю ревизию, это ничем не поможет от системного изменения логики. Потому что окружающий «обвязочный» код уже поменялся, поменялись интерфейсы системы под тестом, объекты тестирования. :)
Кстати, инспекции можно так же запускать на билдерах в качестве элемента сборки. :)
Может быть, мы о разных вещах говорим? Какие такие изменения в логике тестов можно предотвратить/исправить инспекциями или откатом к старой ревизии? Можете конкретный пример привести?
Во-вторых, есть история изменений файла. По ней погулять — тоже не составит проблемы.
В-третьих, если мы «просто откатимся» на древнюю ревизию, это ничем не поможет от системного изменения логики. Потому что окружающий «обвязочный» код уже поменялся, поменялись интерфейсы системы под тестом, объекты тестирования. :)
Кстати, инспекции можно так же запускать на билдерах в качестве элемента сборки. :)
Может быть, мы о разных вещах говорим? Какие такие изменения в логике тестов можно предотвратить/исправить инспекциями или откатом к старой ревизии? Можете конкретный пример привести?
Во-первых, у нас «все тысячи» функциональных тестов гоняются раз в две недели – на выход очередного билда тестируемой программы :) «Не сразу» — для нас это срок максимум в две недели, что тоже существенно.
Во-вторых и в третьих, да вы конечно правы. Мы можем только еще раз повторить, цитату из текста о том, что есть и другие варианты решения проблемы :) Мы не претендуем на роль последней инстанции, но нам, непосредственно в нашем текущем проекте, более всего подошел описанный выше механизм.
Насчет последнего – мы попытались еще раз пояснить в ответе на комментарии ниже.
Во-вторых и в третьих, да вы конечно правы. Мы можем только еще раз повторить, цитату из текста о том, что есть и другие варианты решения проблемы :) Мы не претендуем на роль последней инстанции, но нам, непосредственно в нашем текущем проекте, более всего подошел описанный выше механизм.
Насчет последнего – мы попытались еще раз пояснить в ответе на комментарии ниже.
Ясно, что если тесты запускаются раз в две недели, там будет ад и содомия. Я сейчас на очень напряженном проекте — по 200 — 300 коммитов в день. Если крупно не повезет и билдер ляжет на полдня — разбираться в паре сотен пофейленных тестов — занятие неблагодарное. Рекомендую сокращать циклы до 1 билд на коммит в идеале. :)
Ясно, что если тесты запускаются раз в две недели, там будет ад и содомия
Именно так! :D
разбираться в паре сотен пофейленных тестов — занятие неблагодарное
Это точно… Только вы наверное так часто гоняете всё же юнит-тесты? У нас их тоже перед любой сборкой разработчики запускают. Но наши функциональные тесты – мы бы чисто физически не смогли гонять по нескольку раз в сутки – долго и их много. Насчёт билдов – подумаем, но это всё же не нам (тестировщикам) решать, а PM и тим-лидам))
У нас несколько разных сборок — тесты юнитовые для клиента, для сервера, тесты функциональные серверные. Единственное, мы пока не осилили интеграционные тесты клиент-сервер. Получается слишком хрупко. Специфика проекта — клиент-серверная архитектура с упором на отзывчивость связки клиент-сервер и устойчивость сервера, супер-тослтый клиент :)
>>Однако инспекции бесполезны в случае внесения автоматических изменений в сотни тестов
Можно подробней раскрыть эту фразу? Для чего нужно автоматически изменять тесты и тем более сотни?
Можно подробней раскрыть эту фразу? Для чего нужно автоматически изменять тесты и тем более сотни?
См. ответ выше :).
Дополним :)
Рефакторинг основной тестируемой программы – периодически проводить нужно. Но то, что хорошо при разработке программы, не всегда хорошо при разработке системы её тестирования.
Можно сделать автозамену глобальных констант и переменных, сообщений и т.д., но забыть, что они по-разному использовались в различных тестах, из-за чего может смениться логика их работы.
Сотни функциональных тестов – обычное дело для крупных проектов. В нашем случае, один функциональный тест – это одна функция, которая его реализует. Т.к. тестовая система – это обычная программа, то мы также периодически делаем ее рефакторинг. Но при этом нам нужны гарантии, что код и логика работы самих тестов – не будут затронуты. Кроме того, требуется быстро восстановить изменённые тестовые функции, в случае, если такие изменения всё же произошли.
Рефакторинг основной тестируемой программы – периодически проводить нужно. Но то, что хорошо при разработке программы, не всегда хорошо при разработке системы её тестирования.
Можно сделать автозамену глобальных констант и переменных, сообщений и т.д., но забыть, что они по-разному использовались в различных тестах, из-за чего может смениться логика их работы.
Сотни функциональных тестов – обычное дело для крупных проектов. В нашем случае, один функциональный тест – это одна функция, которая его реализует. Т.к. тестовая система – это обычная программа, то мы также периодически делаем ее рефакторинг. Но при этом нам нужны гарантии, что код и логика работы самих тестов – не будут затронуты. Кроме того, требуется быстро восстановить изменённые тестовые функции, в случае, если такие изменения всё же произошли.
Вы говорите про рефакторинг, но разве это не процесс приводящий систему в тоже самое «видимое» состояние? Ведь если изменился код тестов, но при этом результаты те же, то зачем париться?
Да, вы конечно правы. Наверное будет лучше уточнить задачу так: нам требуется выполнять рефакторинг тестовой системы (запуск тестов, индикаторы состояния проверяемой системы, вспомогательные функции и т.п.), но при этом не затрагивать код и логику работы тестовых функций.
Однако, иногда, обрабатывая множество файлов, используя любые инструменты рефакторинга (того же PyCharm-а), или простую автозамену по множеству файлов, можно случайно внести изменения и в тесты. И закомитить. И не заметить. И разумеется всё будет работать – при рефакторинге же работоспособность остаётся. Но через 2 недели, при прогонке всех тестов для новой сборки тестируемой программы, увидев десятки фейлящихся тестов, которые ранее проходили, вспоминать, а что же тут было в тесте? Это реально фейлы программы? Или кто-то некорректно исправил тесты? Искать причину. Потом, искать код по множеству комитов. Восстанавливать логику их работы. А если тестов тысячи, и писались они в течении почти года?
Однако, иногда, обрабатывая множество файлов, используя любые инструменты рефакторинга (того же PyCharm-а), или простую автозамену по множеству файлов, можно случайно внести изменения и в тесты. И закомитить. И не заметить. И разумеется всё будет работать – при рефакторинге же работоспособность остаётся. Но через 2 недели, при прогонке всех тестов для новой сборки тестируемой программы, увидев десятки фейлящихся тестов, которые ранее проходили, вспоминать, а что же тут было в тесте? Это реально фейлы программы? Или кто-то некорректно исправил тесты? Искать причину. Потом, искать код по множеству комитов. Восстанавливать логику их работы. А если тестов тысячи, и писались они в течении почти года?
Мне кажется Вы более опытный товарищ чем я, поэтому позволю поучать меня как гуру юного подавана.
Вопрос: А почему бы Вам не разделить ваш тестовый код на две части: TestAPI и собственно сами юнит-тесты. Первая часть имеет право меняться и это логично, а вот вторая либо добавляется\либо удаляется\Либо меняется руками специалистом. Получается если Вы неправильно изменили TestAPI, то у Вас упадут больше тестов, т.к. TestAPI общий для всех тестов. А его менять автоматически запретить, только в ручную. Если нужно симмитировать новые тест.ситуации, то вынести это в виде тест-конфигурационных файлы
Вопрос: А почему бы Вам не разделить ваш тестовый код на две части: TestAPI и собственно сами юнит-тесты. Первая часть имеет право меняться и это логично, а вот вторая либо добавляется\либо удаляется\Либо меняется руками специалистом. Получается если Вы неправильно изменили TestAPI, то у Вас упадут больше тестов, т.к. TestAPI общий для всех тестов. А его менять автоматически запретить, только в ручную. Если нужно симмитировать новые тест.ситуации, то вынести это в виде тест-конфигурационных файлы
Да, совершенно верно, по большей части, делается именно такое разделение, как вы написали: отдельно код тестов (у нас — функциональные, не юнит-), отдельно система запуска. Но т.к. команды тестировщиков – всегда небольшие, мы не можем себе позволить выделить отдельного человека, ответственного за дальнейший контроль тестов. Было проще сделать систему ревизий, которая предупредит запускающего тесты, что функции менялись с последней ревизии, и, возможно их надо восстановить.
Можете рассказать, почему не происходит хотя бы ежевечернего запуска всех тестов, чтоб за ночь прошли?
Сейчас именно к этому всё идет. Проблем будет поменьше.
Ранее не было потребности в ночных тестах, т.к. демо-билды были раз в 2 недели и функциональные тесты не проблема было запускать и вручную, а время между итерациями посвящать их разработке. Таким образом, заинтересованная группа лиц – были только разработчики и тестировщики. Но сейчас один продукт будет интегрироваться с другим, и конечно же мы перейдем на автоматизированные ночные тесты.
Ранее не было потребности в ночных тестах, т.к. демо-билды были раз в 2 недели и функциональные тесты не проблема было запускать и вручную, а время между итерациями посвящать их разработке. Таким образом, заинтересованная группа лиц – были только разработчики и тестировщики. Но сейчас один продукт будет интегрироваться с другим, и конечно же мы перейдем на автоматизированные ночные тесты.
Ну, из того, что я вижу по вашим высказываниям, есть несколько процессных проблем. В частности — разделение на «разработчиков» и «тестировщиков». Тестировщики — такие же разработчики, как и программисты и аналитики, и другие участники создания продукта.
Ручной запуск тестов — моветон :)
Зафига их запускать, если демо-билд уже состоялся? Получается, что эти N тысяч тестов — приемочные и больше не используются в процессе разработки? Так тогда у них низкий KPI… :(
Ручной запуск тестов — моветон :)
Зафига их запускать, если демо-билд уже состоялся? Получается, что эти N тысяч тестов — приемочные и больше не используются в процессе разработки? Так тогда у них низкий KPI… :(
Насчет разделения — вы не поняли :) оно условное. Разумеется мы в одной команде с разработчиками и всеми остальными — аджайл-стайл))
Ручной запуск функциональных и приемочных тестов — это нормально. Зачем лишняя автоматизация? Ради автоматизации? Но ведь и так работает, а запустить тестовую систему раз в 2 недели — не проблема. Разумеется также, что полный набор всех тестов прогоняется перед Демонстрацией продукта, на отладочной ветке репозитория. Затем результаты обрабатываются и ставятся задачи по доработке в следующей версии.
Функциональные тесты в разработке используются, но для ежедневного прогона — не полный набор.
Ручной запуск функциональных и приемочных тестов — это нормально. Зачем лишняя автоматизация? Ради автоматизации? Но ведь и так работает, а запустить тестовую систему раз в 2 недели — не проблема. Разумеется также, что полный набор всех тестов прогоняется перед Демонстрацией продукта, на отладочной ветке репозитория. Затем результаты обрабатываются и ставятся задачи по доработке в следующей версии.
Функциональные тесты в разработке используются, но для ежедневного прогона — не полный набор.
Тесты на тесты тестов уже скоро. Не переключайтесь.
Тестов много не бывает, уж лучше избыточный, его хоть удалить можно, чем недостающий, но нужный )
Это конечно правильно, но мы часто, для сокращения числа тестовых случаев, применяем технику pairaise-анализа: http://www.pairwise.org/
Таким образом, выбираем наилучшее покрытие системы тестами с использованием минимального числа тестовых комбинаций.
Таким образом, выбираем наилучшее покрытие системы тестами с использованием минимального числа тестовых комбинаций.
Извините, что придираюсь. Но код вроде как на Python, но оформлен не по PEP-08, рекомендую перед отправкой на публику форматировать в общепринятом стиле
Было бы интересно узнать, в других постах:
1) Опыт тестирования GUI
2) Как тестируете Performance
1) Опыт тестирования GUI
2) Как тестируете Performance
Нас в детстве учили, что тесты проектировать так, чтобы не западло было их запускать на каждый коммит и вообще в любое время, когда захотелось проверить все ли в порядке. Если тесты запускаются раз в две недели, потому что ДОЛГО, что-то в вашей системе не так, раз приходится городить такие костыли. Скорее всего вы не там ищете.
Я думал, что встану с утра и пойму суть проблемы. Но, увы, не удалось понять даже сегодня. Прошу переформулировать мысли, написать user-story по этапам, а не общими словами. Но пока мне кажется, что у Вас какая-то проблема в процессе и ее надо решать, а не делать подобные непонятные зачем кейсы. Хотя согласен в каждой компании свои костыли )
Попытка номер 2 с утра: ) Согласны, проблема была специфическая, только для нашей команды. Но она уже решена, благодаря ревизиям кода и команду вполне устроила.
Суть проблемы: Был активный процесс разработки тестов. Было очень много тестов. Команда каждый день писала еще больше тестов. И, соответственно было много комитов. Периодически, при мерже, по невнимательности, кто-то у кого-то перетирал уже написанные тесты (например, если использовал вызовы уже старых методов, или свои тестовые данные). Как было отмечено выше, после реализации теста и его код-ревью к нему уже не возвращаются и он отправляется на постоянную прогонку. Очень часто, смену логики теста можно было и не заметить. И, например, через какое-то время изменить тест ещё раз уже самому. В итоге, приходилось тратить много времени, отслеживая историю изменения по коду. Это было чрезвычайно неудобно (множество тестов – множество комитов, как отмечал linuxoid выше: «там будет ад и содомия»).
В этом конкретном случае, нам помог механизм ревизий. Написав один раз простенький модуль, и используя его постоянно, мы себя подстраховали. Система сама нас предупредит, если кто-то «несанкционированно» изменил код старых функций. Ничего особенного в таком решении проблемы нет, нашу команду это устроило и мы пользуемся: )
Суть проблемы: Был активный процесс разработки тестов. Было очень много тестов. Команда каждый день писала еще больше тестов. И, соответственно было много комитов. Периодически, при мерже, по невнимательности, кто-то у кого-то перетирал уже написанные тесты (например, если использовал вызовы уже старых методов, или свои тестовые данные). Как было отмечено выше, после реализации теста и его код-ревью к нему уже не возвращаются и он отправляется на постоянную прогонку. Очень часто, смену логики теста можно было и не заметить. И, например, через какое-то время изменить тест ещё раз уже самому. В итоге, приходилось тратить много времени, отслеживая историю изменения по коду. Это было чрезвычайно неудобно (множество тестов – множество комитов, как отмечал linuxoid выше: «там будет ад и содомия»).
В этом конкретном случае, нам помог механизм ревизий. Написав один раз простенький модуль, и используя его постоянно, мы себя подстраховали. Система сама нас предупредит, если кто-то «несанкционированно» изменил код старых функций. Ничего особенного в таком решении проблемы нет, нашу команду это устроило и мы пользуемся: )
Sign up to leave a comment.
Контроль целостности кода функций