Pull to refresh

Comments 32

А что делать если у меня прогон тестов занимет 2 часа?
Мэтры говорят по этому поводу следующее:
Unit tests run fast. If they don't run fast, they aren't unit tests.
Ваши метры наверное не писали ничего сложнее «Здравствуй Мир».

Попробуйте написать тест для алгоритма O(e^n).
Тут, скорее всего, ошибка в определении того, что считать unit-тестами. Есть статья того-же автора по поводу классификации тестов.

Так вот следуя этой классификации unit-тесты — это тесты, которые выполняются очень быстро и проверяют конструкции с условиями перехода (if...else, циклы), которые являются основными источниками багов в коде.

Функциональные и приемочные тесты, чаще всего, выполняются намного дольше и их не следует включать в набор тестов для фонового тестирования в IDE.
юнит тесты должны быть атомарными, собственно, как и методы, для которых они пишутся, в этом идея
Если следовать переводу unit и основам XP, то данный вид тестирования подразумевает тестирование отдельных элементов, в частности для ООП это будут методы классов. Но с учетом эффективности времени разработки обычно тестируется уже взаимодействие между несколькими классами, которое и занимает длительное время.
да, юнит-тестирование подразумевает именно тестирование отдельных элементов, но тестирование кросмодульного взаимодействия это уже не есть юнит-тестирование) функциональные и приемочные тесты — это уже другой этап тестирования
habrahabr.ru/blogs/testing/64874/
Перевел статью, которая даст дает объяснение понятию модульного теста и избавит от некоторых вопросов в комментариях.
Ваши метры наверное не писали ничего сложнее «Здравствуй Мир».
Eah, eah...

Попробуйте написать тест для алгоритма O(e^n).
В чём проблема? Не обязательно тест запускать на наборах данных при n→∞. А при малых n тесты будут отрабатывать быстро.
Для сложных систем данный вариант не подходит. И понятие юнит-тестирования на текущий момент стало весьма растянутым.

Вариант решения — ночные билды с прогоном всех тестов.
нет, вариант решения — это всё-таки билдбот с сеткой билдеров на каждый коммит.
Это только для быстрых тестов (это указано в статье). Для этого можете выделить набор тестов, который будет выполняться за короткое время (2 секунды самое оптимальное).
Так же вариантом является создание нескольких сборщиков, каждый их которых работает с определенным набором тестов и каждый запускается только при изменении определенного набора файлов (это можно установить на вкладке Build Options -> Specify Resources при настройке сборщика)
Автоматический запуск тестов для тех, кто программирует на линухе и тесты держит в отдельных скриптах:
#!/bin/sh

SRC=../src                    # Путь к каталогу с исходниками
TESTS=${@:-./*.t}             # .t -- расширение для тестов по-умолчанию

inotifywait -rm -e close_write $SRC $TESTS | while read line ; do
        clear
        echo ----- $(date) -------
        for t in $TESTS ; do
                echo ">> " $t
                $t || break
        done
done


Перед запуском надо вписать путь к исходникам (SRC=...), потом открыть в отдельном терминале и запустить:
./autotest.sh <test1> <test2> <test3> ...

или, если скрипт находится в катлоге с тестами, и долгих там нет:
./autotest.sh
Сейчас появились инструменты для фонового модульного тестирования, которые умеют определять средствами статического анализа, какие модульные тесты надо выполнить при изменении того или иного фрагмента исходного кода.
Вот тут можно почитать мой перевод обзора таких инструментов на русский язык: software-testing.ru/library/testing/functional-testing/531-background-unit-testing
(Если кто предпочитает английский — там есть ссылка на оригинал)
Хорошая ссылка. Подобные иструменты полезны не только для фонового тестирования — снижение времени прогона тестов еще никому не повредило.
Да, действительно зыкрыл. Что удивительно, но автор (Бек) все-равно не собирается открывать исходники. Похоже провалился его бизнес-план и/или банально нет времени. Дело ясное, что дело темное.
Какой бред. Для автотестирования есть системы continuous integration. А если после каждого сохранения… я вот привык каждые десять секунд сохранять код, что, получается, каждый раз тесты гнать?
А почему бы нет?
Ядер в процессоре много (чем бы их еще загрузить?!), память стоит копейки.
Пусть себе в фоне в отдельной JVM прогоняются.
(1) Цитата: «Для этого тесты должны быть быстрыми, поскольку мое терпение после нажатия Ctrl+s составляет только 2 секунды.»
(2) Вам необъязательно запускать все тесты — а только определенный набор
(3) Тесты выполняются в фоновом режиме — вы не заметите из присутствия до тех пор пока не поломаете тест.

Continuous integration никто не отменял — это один из столпов TDD.
Получается что так, каждые 10 сек запускать тесты, если хочешь быть уверен что ты своими десятисекундными изменениями не поломал что-то.
Никто не заставляет использовать данную технику — кто-то хочет быть уверен в программе каждые 10 секунд, кто-то не обращает на результаты фоновых тестов никакого внимания. В любой момент можно включить/выключить автоматическую прогонку тестов — это дело вкуса и культуры тестирования для каждого отдельно взятого человека.

— Я поломаю этот проект за 7 секунд.
— А я за 5.
— Ломай.

© Угадай Мелодию
а что если прогон тестов занимает почти 2 часа да ещё и на нескольких платформах? Какая-то идиотская идея, вот что это.
А разве проект нельзя поделить на несколько подпроектов и назначить для каждого из них свой набор тестов? В Visual Studio так обычно и делается.
да все равно в 2секунды уложится слишком нереально — вот я к чему.
все здорово, только порой сложно убедить начальство в подходе с модульным тестирование, особенно если еще и код унаследован и для интеграции нужно много времени… Сложно обьяснить что потом экономия будет офигенной…

P.S. хочу постер как картинка к статье ;) повешу напротив начальника )))
Sign up to leave a comment.

Articles