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