Comments 32
А что делать если у меня прогон тестов занимет 2 часа?
Мэтры говорят по этому поводу следующее:
Unit tests run fast. If they don't run fast, they aren't unit tests.
Ваши метры наверное не писали ничего сложнее «Здравствуй Мир».
Попробуйте написать тест для алгоритма O(e^n).
Попробуйте написать тест для алгоритма O(e^n).
Тут, скорее всего, ошибка в определении того, что считать unit-тестами. Есть статья того-же автора по поводу классификации тестов.
Так вот следуя этой классификации unit-тесты — это тесты, которые выполняются очень быстро и проверяют конструкции с условиями перехода (if...else, циклы), которые являются основными источниками багов в коде.
Функциональные и приемочные тесты, чаще всего, выполняются намного дольше и их не следует включать в набор тестов для фонового тестирования в IDE.
Так вот следуя этой классификации unit-тесты — это тесты, которые выполняются очень быстро и проверяют конструкции с условиями перехода (if...else, циклы), которые являются основными источниками багов в коде.
Функциональные и приемочные тесты, чаще всего, выполняются намного дольше и их не следует включать в набор тестов для фонового тестирования в IDE.
юнит тесты должны быть атомарными, собственно, как и методы, для которых они пишутся, в этом идея
Если следовать переводу unit и основам XP, то данный вид тестирования подразумевает тестирование отдельных элементов, в частности для ООП это будут методы классов. Но с учетом эффективности времени разработки обычно тестируется уже взаимодействие между несколькими классами, которое и занимает длительное время.
habrahabr.ru/blogs/testing/64874/
Перевел статью, которая даст дает объяснение понятию модульного теста и избавит от некоторых вопросов в комментариях.
Перевел статью, которая даст дает объяснение понятию модульного теста и избавит от некоторых вопросов в комментариях.
Ваши метры наверное не писали ничего сложнее «Здравствуй Мир».Eah, eah...
Попробуйте написать тест для алгоритма O(e^n).В чём проблема? Не обязательно тест запускать на наборах данных при n→∞. А при малых n тесты будут отрабатывать быстро.
Для сложных систем данный вариант не подходит. И понятие юнит-тестирования на текущий момент стало весьма растянутым.
Вариант решения — ночные билды с прогоном всех тестов.
Вариант решения — ночные билды с прогоном всех тестов.
Это только для быстрых тестов (это указано в статье). Для этого можете выделить набор тестов, который будет выполняться за короткое время (2 секунды самое оптимальное).
Нужно просто пользоваться Maven'ом!
Автоматический запуск тестов для тех, кто программирует на линухе и тесты держит в отдельных скриптах:
Перед запуском надо вписать путь к исходникам (SRC=...), потом открыть в отдельном терминале и запустить:
или, если скрипт находится в катлоге с тестами, и долгих там нет:
#!/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
(Если кто предпочитает английский — там есть ссылка на оригинал)
Вот тут можно почитать мой перевод обзора таких инструментов на русский язык: software-testing.ru/library/testing/functional-testing/531-background-unit-testing
(Если кто предпочитает английский — там есть ссылка на оригинал)
Хорошая ссылка. Подобные иструменты полезны не только для фонового тестирования — снижение времени прогона тестов еще никому не повредило.
Увы, проект JUnitMax был только что закрыт автором.
Недостаточно пользователей.
www.threeriversinstitute.org/blog/?p=291
Недостаточно пользователей.
www.threeriversinstitute.org/blog/?p=291
Да, действительно зыкрыл. Что удивительно, но автор (Бек) все-равно не собирается открывать исходники. Похоже провалился его бизнес-план и/или банально нет времени. Дело ясное, что дело темное.
Упс… А как красиво про стартапы писал — www.threeriversinstitute.org/blog/?p=251
Ну и ладно, главное — что идея появилась, кто-нибудь другой реализует.
Ну и ладно, главное — что идея появилась, кто-нибудь другой реализует.
Какой бред. Для автотестирования есть системы continuous integration. А если после каждого сохранения… я вот привык каждые десять секунд сохранять код, что, получается, каждый раз тесты гнать?
А почему бы нет?
Ядер в процессоре много (чем бы их еще загрузить?!), память стоит копейки.
Пусть себе в фоне в отдельной JVM прогоняются.
Ядер в процессоре много (чем бы их еще загрузить?!), память стоит копейки.
Пусть себе в фоне в отдельной JVM прогоняются.
(1) Цитата: «Для этого тесты должны быть быстрыми, поскольку мое терпение после нажатия Ctrl+s составляет только 2 секунды.»
(2) Вам необъязательно запускать все тесты — а только определенный набор
(3) Тесты выполняются в фоновом режиме — вы не заметите из присутствия до тех пор пока не поломаете тест.
Continuous integration никто не отменял — это один из столпов TDD.
(2) Вам необъязательно запускать все тесты — а только определенный набор
(3) Тесты выполняются в фоновом режиме — вы не заметите из присутствия до тех пор пока не поломаете тест.
Continuous integration никто не отменял — это один из столпов TDD.
Получается что так, каждые 10 сек запускать тесты, если хочешь быть уверен что ты своими десятисекундными изменениями не поломал что-то.
Никто не заставляет использовать данную технику — кто-то хочет быть уверен в программе каждые 10 секунд, кто-то не обращает на результаты фоновых тестов никакого внимания. В любой момент можно включить/выключить автоматическую прогонку тестов — это дело вкуса и культуры тестирования для каждого отдельно взятого человека.
— Я поломаю этот проект за 7 секунд.
— А я за 5.
— Ломай.
© Угадай Мелодию
— А я за 5.
— Ломай.
© Угадай Мелодию
По использованию Ant можно почитать www.artlebedev.ru/tools/technogrette/soft/eclipse-ant/
а что если прогон тестов занимает почти 2 часа да ещё и на нескольких платформах? Какая-то идиотская идея, вот что это.
все здорово, только порой сложно убедить начальство в подходе с модульным тестирование, особенно если еще и код унаследован и для интеграции нужно много времени… Сложно обьяснить что потом экономия будет офигенной…
P.S. хочу постер как картинка к статье ;) повешу напротив начальника )))
P.S. хочу постер как картинка к статье ;) повешу напротив начальника )))
Sign up to leave a comment.
Настройка IDE для автоматического запуска тестов