Нет, конечно не только. У нас был Call For Papers в ходе которого можно было заявки на выступление отправлять, так что будут докладчики из разных организаций/компаний/стран :).
Ну это как сказать. Семинары некоторых экспертов, что будут на PHDays, по одному стоят примерно как билет на два дня форума. Так что все относительно :). В любом случае, мы работаем и над организацией трансляции с площадки.
Попытка номер 2 с утра: ) Согласны, проблема была специфическая, только для нашей команды. Но она уже решена, благодаря ревизиям кода и команду вполне устроила.
Суть проблемы: Был активный процесс разработки тестов. Было очень много тестов. Команда каждый день писала еще больше тестов. И, соответственно было много комитов. Периодически, при мерже, по невнимательности, кто-то у кого-то перетирал уже написанные тесты (например, если использовал вызовы уже старых методов, или свои тестовые данные). Как было отмечено выше, после реализации теста и его код-ревью к нему уже не возвращаются и он отправляется на постоянную прогонку. Очень часто, смену логики теста можно было и не заметить. И, например, через какое-то время изменить тест ещё раз уже самому. В итоге, приходилось тратить много времени, отслеживая историю изменения по коду. Это было чрезвычайно неудобно (множество тестов – множество комитов, как отмечал linuxoid выше: «там будет ад и содомия»).
В этом конкретном случае, нам помог механизм ревизий. Написав один раз простенький модуль, и используя его постоянно, мы себя подстраховали. Система сама нас предупредит, если кто-то «несанкционированно» изменил код старых функций. Ничего особенного в таком решении проблемы нет, нашу команду это устроило и мы пользуемся: )
Насчет разделения — вы не поняли :) оно условное. Разумеется мы в одной команде с разработчиками и всеми остальными — аджайл-стайл))
Ручной запуск функциональных и приемочных тестов — это нормально. Зачем лишняя автоматизация? Ради автоматизации? Но ведь и так работает, а запустить тестовую систему раз в 2 недели — не проблема. Разумеется также, что полный набор всех тестов прогоняется перед Демонстрацией продукта, на отладочной ветке репозитория. Затем результаты обрабатываются и ставятся задачи по доработке в следующей версии.
Функциональные тесты в разработке используются, но для ежедневного прогона — не полный набор.
Это конечно правильно, но мы часто, для сокращения числа тестовых случаев, применяем технику pairaise-анализа: http://www.pairwise.org/
Таким образом, выбираем наилучшее покрытие системы тестами с использованием минимального числа тестовых комбинаций.
Сейчас именно к этому всё идет. Проблем будет поменьше.
Ранее не было потребности в ночных тестах, т.к. демо-билды были раз в 2 недели и функциональные тесты не проблема было запускать и вручную, а время между итерациями посвящать их разработке. Таким образом, заинтересованная группа лиц – были только разработчики и тестировщики. Но сейчас один продукт будет интегрироваться с другим, и конечно же мы перейдем на автоматизированные ночные тесты.
Ясно, что если тесты запускаются раз в две недели, там будет ад и содомия
Именно так! :D
разбираться в паре сотен пофейленных тестов — занятие неблагодарное
Это точно… Только вы наверное так часто гоняете всё же юнит-тесты? У нас их тоже перед любой сборкой разработчики запускают. Но наши функциональные тесты – мы бы чисто физически не смогли гонять по нескольку раз в сутки – долго и их много. Насчёт билдов – подумаем, но это всё же не нам (тестировщикам) решать, а PM и тим-лидам))
Во-первых, у нас «все тысячи» функциональных тестов гоняются раз в две недели – на выход очередного билда тестируемой программы :) «Не сразу» — для нас это срок максимум в две недели, что тоже существенно.
Во-вторых и в третьих, да вы конечно правы. Мы можем только еще раз повторить, цитату из текста о том, что есть и другие варианты решения проблемы :) Мы не претендуем на роль последней инстанции, но нам, непосредственно в нашем текущем проекте, более всего подошел описанный выше механизм.
Насчет последнего – мы попытались еще раз пояснить в ответе на комментарии ниже.
Да, совершенно верно, по большей части, делается именно такое разделение, как вы написали: отдельно код тестов (у нас — функциональные, не юнит-), отдельно система запуска. Но т.к. команды тестировщиков – всегда небольшие, мы не можем себе позволить выделить отдельного человека, ответственного за дальнейший контроль тестов. Было проще сделать систему ревизий, которая предупредит запускающего тесты, что функции менялись с последней ревизии, и, возможно их надо восстановить.
Да, вы конечно правы. Наверное будет лучше уточнить задачу так: нам требуется выполнять рефакторинг тестовой системы (запуск тестов, индикаторы состояния проверяемой системы, вспомогательные функции и т.п.), но при этом не затрагивать код и логику работы тестовых функций.
Однако, иногда, обрабатывая множество файлов, используя любые инструменты рефакторинга (того же PyCharm-а), или простую автозамену по множеству файлов, можно случайно внести изменения и в тесты. И закомитить. И не заметить. И разумеется всё будет работать – при рефакторинге же работоспособность остаётся. Но через 2 недели, при прогонке всех тестов для новой сборки тестируемой программы, увидев десятки фейлящихся тестов, которые ранее проходили, вспоминать, а что же тут было в тесте? Это реально фейлы программы? Или кто-то некорректно исправил тесты? Искать причину. Потом, искать код по множеству комитов. Восстанавливать логику их работы. А если тестов тысячи, и писались они в течении почти года?
Рефакторинг основной тестируемой программы – периодически проводить нужно. Но то, что хорошо при разработке программы, не всегда хорошо при разработке системы её тестирования.
Можно сделать автозамену глобальных констант и переменных, сообщений и т.д., но забыть, что они по-разному использовались в различных тестах, из-за чего может смениться логика их работы.
Сотни функциональных тестов – обычное дело для крупных проектов. В нашем случае, один функциональный тест – это одна функция, которая его реализует. Т.к. тестовая система – это обычная программа, то мы также периодически делаем ее рефакторинг. Но при этом нам нужны гарантии, что код и логика работы самих тестов – не будут затронуты. Кроме того, требуется быстро восстановить изменённые тестовые функции, в случае, если такие изменения всё же произошли.
существуют и альтернативные варианты решения проблемы, например, инспекции кода и использование инструментов в репозиториях (например, GIT, SVN). Однако инспекции бесполезны в случае внесения автоматических изменений в сотни тестов, а отслеживание изменений в коде с помощью инструментов репозитория после нескольких мержей — процесс трудоемкий и долгий.
В действительности:
— есть наборы с сотнями тестов, которые написали и забыли,
— есть необходимость периодического рефакторинга тестовой системы, при котором не должны вноситься изменения в логику тестов, но тем не менее, иногда вносятся.
— проверять «все, которые упали из-за рефакторинга — поправить; или откатить рефакторинг» — не вариант, т.к. замечают изменения в логике тестов не сразу, а когда замечают, искать изменённые кусочки кода в git-е – долго.
Один раз было потрачено несколько часов, только для того, чтобы восстановить логику работы и код всего восьми тестов, потому что было сделано уже множество мержей поверх. Кроме того, забывается, как именно должны работать эти тесты. Сейчас, в ситуациях с изменением кода множества тестовых функций, достаточно скопировать их целиком из ревизии, и не мучаться с поисками всех мержей.
Пробовали и используем. Действительно, в некоторых случаях работает более эффективно чем студийный build без clean. Для MSVS эта штука называется clcache, мы немного отредактировали ее первоначальный вариант отсюда https://github.com/frerich/clcache
Как вы внимательно смотрели видео :)
Да, к сожалению, при подготовке презентации в данные вкралась ошибка. По старым данным получалось что строка кода у нас длиной под 300 символов :)
Суть проблемы: Был активный процесс разработки тестов. Было очень много тестов. Команда каждый день писала еще больше тестов. И, соответственно было много комитов. Периодически, при мерже, по невнимательности, кто-то у кого-то перетирал уже написанные тесты (например, если использовал вызовы уже старых методов, или свои тестовые данные). Как было отмечено выше, после реализации теста и его код-ревью к нему уже не возвращаются и он отправляется на постоянную прогонку. Очень часто, смену логики теста можно было и не заметить. И, например, через какое-то время изменить тест ещё раз уже самому. В итоге, приходилось тратить много времени, отслеживая историю изменения по коду. Это было чрезвычайно неудобно (множество тестов – множество комитов, как отмечал linuxoid выше: «там будет ад и содомия»).
В этом конкретном случае, нам помог механизм ревизий. Написав один раз простенький модуль, и используя его постоянно, мы себя подстраховали. Система сама нас предупредит, если кто-то «несанкционированно» изменил код старых функций. Ничего особенного в таком решении проблемы нет, нашу команду это устроило и мы пользуемся: )
Ручной запуск функциональных и приемочных тестов — это нормально. Зачем лишняя автоматизация? Ради автоматизации? Но ведь и так работает, а запустить тестовую систему раз в 2 недели — не проблема. Разумеется также, что полный набор всех тестов прогоняется перед Демонстрацией продукта, на отладочной ветке репозитория. Затем результаты обрабатываются и ставятся задачи по доработке в следующей версии.
Функциональные тесты в разработке используются, но для ежедневного прогона — не полный набор.
Таким образом, выбираем наилучшее покрытие системы тестами с использованием минимального числа тестовых комбинаций.
Ранее не было потребности в ночных тестах, т.к. демо-билды были раз в 2 недели и функциональные тесты не проблема было запускать и вручную, а время между итерациями посвящать их разработке. Таким образом, заинтересованная группа лиц – были только разработчики и тестировщики. Но сейчас один продукт будет интегрироваться с другим, и конечно же мы перейдем на автоматизированные ночные тесты.
Именно так! :D
Это точно… Только вы наверное так часто гоняете всё же юнит-тесты? У нас их тоже перед любой сборкой разработчики запускают. Но наши функциональные тесты – мы бы чисто физически не смогли гонять по нескольку раз в сутки – долго и их много. Насчёт билдов – подумаем, но это всё же не нам (тестировщикам) решать, а PM и тим-лидам))
Во-вторых и в третьих, да вы конечно правы. Мы можем только еще раз повторить, цитату из текста о том, что есть и другие варианты решения проблемы :) Мы не претендуем на роль последней инстанции, но нам, непосредственно в нашем текущем проекте, более всего подошел описанный выше механизм.
Насчет последнего – мы попытались еще раз пояснить в ответе на комментарии ниже.
Однако, иногда, обрабатывая множество файлов, используя любые инструменты рефакторинга (того же PyCharm-а), или простую автозамену по множеству файлов, можно случайно внести изменения и в тесты. И закомитить. И не заметить. И разумеется всё будет работать – при рефакторинге же работоспособность остаётся. Но через 2 недели, при прогонке всех тестов для новой сборки тестируемой программы, увидев десятки фейлящихся тестов, которые ранее проходили, вспоминать, а что же тут было в тесте? Это реально фейлы программы? Или кто-то некорректно исправил тесты? Искать причину. Потом, искать код по множеству комитов. Восстанавливать логику их работы. А если тестов тысячи, и писались они в течении почти года?
Рефакторинг основной тестируемой программы – периодически проводить нужно. Но то, что хорошо при разработке программы, не всегда хорошо при разработке системы её тестирования.
Можно сделать автозамену глобальных констант и переменных, сообщений и т.д., но забыть, что они по-разному использовались в различных тестах, из-за чего может смениться логика их работы.
Сотни функциональных тестов – обычное дело для крупных проектов. В нашем случае, один функциональный тест – это одна функция, которая его реализует. Т.к. тестовая система – это обычная программа, то мы также периодически делаем ее рефакторинг. Но при этом нам нужны гарантии, что код и логика работы самих тестов – не будут затронуты. Кроме того, требуется быстро восстановить изменённые тестовые функции, в случае, если такие изменения всё же произошли.
В действительности:
— есть наборы с сотнями тестов, которые написали и забыли,
— есть необходимость периодического рефакторинга тестовой системы, при котором не должны вноситься изменения в логику тестов, но тем не менее, иногда вносятся.
— проверять «все, которые упали из-за рефакторинга — поправить; или откатить рефакторинг» — не вариант, т.к. замечают изменения в логике тестов не сразу, а когда замечают, искать изменённые кусочки кода в git-е – долго.
Один раз было потрачено несколько часов, только для того, чтобы восстановить логику работы и код всего восьми тестов, потому что было сделано уже множество мержей поверх. Кроме того, забывается, как именно должны работать эти тесты. Сейчас, в ситуациях с изменением кода множества тестовых функций, достаточно скопировать их целиком из ревизии, и не мучаться с поисками всех мержей.
Да, к сожалению, при подготовке презентации в данные вкралась ошибка. По старым данным получалось что строка кода у нас длиной под 300 символов :)