Работаю на большом проекте (длится несколько лет, всего занято 30-40 разработчиков, относительно высокая текучка). Проект — веб-приложение, по большому счету формоклепательство. Основные технологии: J2EE, Oracle, jQuery.
Одна из вещей, которая меня расстраивает на проекте: разработчики мало (относительно мало, относительно 100% покрытия) пишут тесты. Кто-то пишет от случая к случаю, кто-то не пишет вообще (еще и чужие выключают частенько, но речь не об этом).
Когда задаю вопрос, почему не написал тесты на новый код, часто слышу ответ: времени не было, собирался написать после выполнения задачи (т.е. когда код уже отлажен, закомичен и часто даже проверен тестировщиками). Для меня это очень странно, потому что у нас на проекте очень хорошая инфраструктура для тестов, их разработка тривиальна, не занимает много времени, ничего самому изобретать не надо, как правило. Я сам всегда пишу тесты для нового кода, мне так легче его проверить, чем собирать все приложение целиком, совершать телодвижения для проверки всего в интеграции. Но при этом я не пишу много тестов, не стремлюсь к полному покрытию, обычно это несколько смок-тестов и доп. проверки на хитрые случаи в зависимости от нетривиальности кода, своего рода баланс между временем на написание тестов и полнотой покрытия. Если требуется исправить ошибку, обычно сначала пишу тест, который локализует ошибку, затем исправляю код, и проверяю что тест проходит. В целом я считаю, что экономлю много времени уже на этом этапе, даже если забыть о пользе существования таких тестов на будущее (например, снижение риска переоткрытия ранее исправленных ошибок, что, к сожалению, на нашем проекте не редкость).
Теперь о чем мой вопрос. А есть ли вообще смысл писать тесты после отладки кода? Очевидный ответ да, ведь так будет больше шансов что функционал останется работоспособным в будущем, в него легче вносить изменения для меня несколько спорен. Во-первых, этот эффект проявится не сразу, а в каком-то туманном будущем. Во-вторых, вероятность что пользу почувствует именно автор, тоже далеко не 100%. С одной стороны это в перспективе демотивирует писать тесты, а с другой — снижает стимул писать именно хорошие, полезные тесты (да и сложнее отличить хорошие от плохих в этом случае) с большим покрытием. Ведь при отладке кода уже было исправлено много ошибок, если бы на каждую ошибку был написан тест, к завершению отладки мы бы получили пачку тестов, выявляющих проблемы, которые реально могут возникнуть.
Есть и другой момент в таком подходе. Когда пишешь тесты после выполнения задачи, к ним отношения как к некой дополнительной работе, которую можно делать, можно не делать, все равно никто проверять (тестировщики) не станут и по шее не дадут, как за ошибки. Забивание на тесты в данном случае это вполне объяснимое следствие. Но даже если тесты и будут написаны, это будет сделано через силу и вряд ли результат получится хорошего качества.
Третье возражение, это не смотря на всю простоту, поддержка и разработка тестов требуют каких-то затрат. Может оказаться что эти затраты никогда не отобьются. Заморозили фичу, удалили или полностью переделали заново, тоже не редкое явление. В случае разработки тестов до отладки кода, часть этих затрат (уверен, что в некоторых случаях эта часть превышает 100%) уже отбилась на этапе отладки. Поэтому возникает вопрос нужны ли вообще тесты, если речь идет не о разработке ядерного реактора и ценой ошибки можно пренебречь, если важнее эффективность в плане трудозатрат разработки.
Вторая тема, которую хотелось бы обсудить, это причины по которым разработчики не используют тесты для отладки кода. У меня есть некоторые размышления на этот счет, но хотелось бы послушать именно тех, кто не всегда пишет тесты и почему вы этого не делаете, что мешает начать писать.
Если есть успешный опыт внедрения процесса написания тестов в проекте, тоже было бы интересно послушать.
Здравствуйте, vb-develop, Вы писали:
VD>Вторая тема, которую хотелось бы обсудить, это причины по которым разработчики не используют тесты для отладки кода. У меня есть некоторые размышления на этот счет, но хотелось бы послушать именно тех, кто не всегда пишет тесты и почему вы этого не делаете, что мешает начать писать.
В одном из проектов написание кода занимало 4 часа, а написание теста для него — от 8 до 16 часов. Как ты догадываешься, в таких условиях надо оооочень хотеть писать тесты.
На другом проекте все еще хуже — данные плохо формализуются и написание тестов для автоматической проверки некоторых задач может потянуть на PhD. Поэтому проще сделать собственный отладчик и вручную проверять работу алгоритмов. Ну и ассерты помогают.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, vb-develop, Вы писали:
VD>Если есть успешный опыт внедрения процесса написания тестов в проекте, тоже было бы интересно послушать.
Source control vertion плагин для 8 студии нехорошо сохраняет в SVN тесты, в результате тесты хранить вместе с проектом затруднительно, а это сильно мешает их использованию.
Здравствуйте, vb-develop, Вы писали:
VD>Одна из вещей, которая меня расстраивает на проекте: разработчики мало (относительно мало, относительно 100% покрытия) пишут тесты.
А какова твоя-то роль в проекте? Ты рядовой разработчик, или тимлид, или PM?
SVZ>В одном из проектов написание кода занимало 4 часа, а написание теста для него — от 8 до 16 часов.
Это косвенно указывает на качество кода. Использовать его так же сложно, а рефакторинг или расширение функциональности превращаются в кошмар.
SVZ>На другом проекте все еще хуже — данные плохо формализуются и написание тестов для автоматической проверки некоторых задач может потянуть на PhD. Поэтому проще сделать собственный отладчик и вручную проверять работу алгоритмов. Ну и ассерты помогают.
Если логику можно проверить вручную, то это можно сделать и автоматически. Не нужно пытаться получить общее решение с формализованными данными, для начала достаточно набора prerecorded data.
VD>Теперь о чем мой вопрос. А есть ли вообще смысл писать тесты после отладки кода?
Обязательно. Как правило на реальных проектах довольно хреново с покрытием кода тестами и вопрос о том, какой участок следует покрывать в первую очередь похож на вопрос "где проводить оптимизацию". Очень легко ошибиться и начать писать тесты не там, где они в данный момент нужны больше всего. Хорошим индикатором такого места являются баги — сломалось, починили, заодно и тесты написали. Обычно в процессе написания тестов выявляется еще два-три бага. В это время их удобно править, потому что все еще свежо в мозгах и легко не упустить никакие мелочи или побочные эффекты.
Здравствуйте, Vlad_SP, Вы писали:
V_S>Здравствуйте, vb-develop, Вы писали:
VD>>Одна из вещей, которая меня расстраивает на проекте: разработчики мало (относительно мало, относительно 100% покрытия) пишут тесты.
V_S>А какова твоя-то роль в проекте? Ты рядовой разработчик, или тимлид, или PM?
Очень интересно на что это влияет в плане обозначенной проблемы. При старте (недолго, до первой альфы) проекта был разработчиком, потом проект расширили и с тех пор работаю в роли тимлида.
Здравствуйте, abibok, Вы писали:
VD>>Теперь о чем мой вопрос. А есть ли вообще смысл писать тесты после отладки кода?
A>Обязательно. Как правило на реальных проектах довольно хреново с покрытием кода тестами и вопрос о том, какой участок следует покрывать в первую очередь похож на вопрос "где проводить оптимизацию". Очень легко ошибиться и начать писать тесты не там, где они в данный момент нужны больше всего. Хорошим индикатором такого места являются баги — сломалось, починили, заодно и тесты написали.
Я полностью поддерживаю такой подход При правке багов надо писать тесты, здесь у меня никаких сомнений. Мой вопрос был именно про написания тестов до появления багов, но после завершения отладки кода и выполнения задачи.
Здравствуйте, abibok, Вы писали:
SVZ>>В одном из проектов написание кода занимало 4 часа, а написание теста для него — от 8 до 16 часов.
A>Это косвенно указывает на качество кода. Использовать его так же сложно, а рефакторинг или расширение функциональности превращаются в кошмар.
Никуда это не указывает Одно дело — протестировать какой-нибудь контейнер (что положил, то и взял), другое — какой-нибудь алгоритм, да еще асинхронный.
Конкретно в этом случае был VoIP проект. Факт приема сигнала автоматически проверить можно. На слух оценить качество принимаемого сигнала тоже можно. Как оценить автоматически? Анализ спектра? Это может и не тянет на кандидатскую, но и за 5 минут не напишешь. А сложность теста будет такова, что на него придется писать собственные тесты
A>Если логику можно проверить вручную, то это можно сделать и автоматически. Не нужно пытаться получить общее решение с формализованными данными, для начала достаточно набора prerecorded data.
Мне "везет" работать с данными непредсказуемого качества.
Т.е. если следовать спецификации, использовать prerecorded данные, то все работает. А на реальных данных — хрен.
Поэтому у нас тесты применяются очень ограниченно. Больше используются run-time ассерты.
_____________________
С уважением,
Stanislav V. Zudin
A>>Это косвенно указывает на качество кода. Использовать его так же сложно, а рефакторинг или расширение функциональности превращаются в кошмар. SVZ>Никуда это не указывает
Указывает-указывает. В коде все части сильно связаны между собой, сложно протестировать отдельный компонент в изоляции, компоненты требуют сложного сетапа/конфигурации прежде чем можно будет хотя бы создать объект и вызвать его метод. Поэтому юнит тесты пишутся со скрипом и на самом деле являются ориентированными на реализацию интеграционными тестами. Соответственно любое изменение проекта ведет к большим переделкам тестов. А проблема здесь в том, что проект изначально разрабатывался без тестов.
SVZ> Одно дело — протестировать какой-нибудь контейнер (что положил, то и взял), другое — какой-нибудь алгоритм, да еще асинхронный.
Протестировать можно все. Другое дело, что не все участки кода тестировать обязательно. Имея тесты вы всегда знаете качество каждого участка и можете принять решение о том, нужно ли добавлять тесты для данной области или нет. А без тестов вам остается только верить "вроде пока не падает, значит пока не сломали".
VD>Мой вопрос был именно про написания тестов до появления багов, но после завершения отладки кода и выполнения задачи.
Тоже нужно, если видно, что новая функциональность уже не покрывается существующими тестами или появились какие-то новые use cases.
Тесты — самая лучшая документация. Кроме того, в будущем найдутся баги и нужно будет писать тесты до/после их исправления. Проще расширить существующий тест, чем писать новый с нуля. И отлаживать код по тестам проще.
VD>Теперь о чем мой вопрос. А есть ли вообще смысл писать тесты после отладки кода?
Ну, задачи в жизни всякие встречаются. Бывают и такие задачи, в которых срок исполнения приоритетней, чем качество. Например, кровь из носу сделать такую-то фичу к такому-то числу, чтобы она более-менее сносно работала, а там посмотрим.
И в такой ситуации как раз уместно писать тесты после отладки. Например, сначала к жесткому дедлайну код написали, худо-бедно отладили, вроде бы оно работает и не падает. Но разработчика гложут сомнения: "а вдруг упадет?"
Вот тут хорошо бы было написать еще несколько тестов, проверить всякие исключительные случаи, про которые в запарке могли забыть. Лучше самому обнаружить багу и вовремя выпустить патчик, чем потом срочно выпускать патчик в ответ на гневную реакцию пользователей или заказчиков, неожиданно наткнувшихся на багу.
Здравствуйте, vb-develop, Вы писали:
VD>Работаю на большом проекте (длится несколько лет, всего занято 30-40 разработчиков, относительно высокая текучка). Проект — веб-приложение, по большому счету формоклепательство. Основные технологии: J2EE, Oracle, jQuery.
VD>Одна из вещей, которая меня расстраивает на проекте: разработчики мало (относительно мало, относительно 100% покрытия) пишут тесты. Кто-то пишет от случая к случаю, кто-то не пишет вообще (еще и чужие выключают частенько, но речь не об этом).
тесты нужны для того, чтобы заставить людей писать более модульный код.
потому что тестировать немодульные вещи от "8 до 10 часов" на тест как тут уже приводили пример. сплошное мучение.
можно писать качественный код без тестов. можно с тестами. если код нетестируемый и глючный, то просто уровень команды низкий, нужно искать что-то другое, если хочется расти.
K>Ну, задачи в жизни всякие встречаются. Бывают и такие задачи, в которых срок исполнения приоритетней, чем качество. Например, кровь из носу сделать такую-то фичу к такому-то числу, чтобы она более-менее сносно работала, а там посмотрим. K>И в такой ситуации как раз уместно писать тесты после отладки. Например, сначала к жесткому дедлайну код написали, худо-бедно отладили, вроде бы оно работает и не падает. Но разработчика гложут сомнения: "а вдруг упадет?" K>Вот тут хорошо бы было написать еще несколько тестов, проверить всякие исключительные случаи, про которые в запарке могли забыть. Лучше самому обнаружить багу и вовремя выпустить патчик, чем потом срочно выпускать патчик в ответ на гневную реакцию пользователей или заказчиков, неожиданно наткнувшихся на багу.
Разработчики пишут юнит-тесты вместе с написанием кода. Параллельно с ними работают тестеры, которые пишут functional, integration, model-based тесты. В какой-то момент фича объявляется законченной и тестерами обещается, что никаких изменений в коде уже не будет, будут только исправления ошибок. После этого тестеры продолжают писать новые тесты еще некоторое время, пока не будет выполнен тест-план фичи. Одновременно пишутся и запускаются longhaul тесты с критерием "X часов непрерывного выполнения сценариев без сбоев".
Здравствуйте, abibok, Вы писали:
A>Другое дело, что не все участки кода тестировать обязательно.
А надо до начала не то что написания — до начала проектирования угадать, какие участки обязательные, а какие — нет, и написать для них тесты?
A>Имея тесты вы всегда знаете качество каждого участка и можете принять решение о том, нужно ли добавлять тесты для данной области или нет.
Имея тесты можно принять решение добавлять ли тесты.
A>Разработчики пишут юнит-тесты вместе с написанием кода. Параллельно с ними работают тестеры, которые пишут functional, integration, model-based тесты. В какой-то момент фича объявляется законченной и тестерами обещается, что никаких изменений в коде уже не будет, будут только исправления ошибок. После этого тестеры продолжают писать новые тесты еще некоторое время, пока не будет выполнен тест-план фичи. Одновременно пишутся и запускаются longhaul тесты с критерием "X часов непрерывного выполнения сценариев без сбоев".
Это все верно, но есть два нюанса.
Во-первых, в реальной жизни выполнение тест-плана может быть завершено как до, так и после выпуска продукта (ну, там жесткий делайн и все такое... неработающий продукт выпустить нельзя, недотестированный — иногда можно).
Во-вторых, тест-план — это не жесткая догма, а он может меняться со временем. Например, от заказчика может поступить фидбек: "что-то вот эта фича хреновато работает", тогда может понадобиться ее еще потестировать сверх запланированного.
Y>А надо до начала не то что написания — до начала проектирования угадать, какие участки обязательные, а какие — нет, и написать для них тесты?
На практике угадывать с тестами — примерно то же самое, что угадывать с оптимизацией. На этапе проектирования можно разработать и test spec (не test plan), но бросаться писать абстрактные тесты того, чего еще нет даже в черновом варианте я бы не стал.
Y>Имея тесты можно принять решение добавлять ли тесты.
А как иначе? Имея тесты вы представляете себе степень покрытия каждой фичи, а также можете оценить риски — чем аукнется баг в данной области, и решить писать новые/улучшать существующие или потратить ресурсы в другом месте. Не имея тестов вы слепы.
K>Во-первых, в реальной жизни выполнение тест-плана может быть завершено как до, так и после выпуска продукта (ну, там жесткий делайн и все такое... неработающий продукт выпустить нельзя, недотестированный — иногда можно).
Разве я утверждал, что такое невозможно? У продукта может быть много фич и для каждой фичи свой тест план. При условии неограниченных ресурсов можно придумать такие тест планы, что работы хватит на год вперед. На практике же решение о релизе продукта делается, когда качество по итогам тестирования "good enough", т.е. выгоднее выпустить сейчас, чем продолжать тестировать и выпустить через месяц. Никто не пытается выловить и исправить абсолютно все баги.
K>Во-вторых, тест-план — это не жесткая догма, а он может меняться со временем. Например, от заказчика может поступить фидбек: "что-то вот эта фича хреновато работает", тогда может понадобиться ее еще потестировать сверх запланированного.
И снова вы спорите не со мной. Все меняется, и требуемая функциональность продукта, и тест планы. Но для правильно поставленного процесса разработки это не имеет значения. Продукт готов к релизу в каждый момент и в каждый момент мы имеем представление о его качестве и потенциально слабых местах.
SVZ>На другом проекте все еще хуже — данные плохо формализуются и написание тестов для автоматической проверки некоторых задач может потянуть на PhD. Поэтому проще сделать собственный отладчик и вручную проверять работу алгоритмов. Ну и ассерты помогают.
Звучит странно. Даже в таких непростых областях как классификация изображений , тесты очень неплохо используются. поделитесь задачей
