SVZ>В одном из проектов написание кода занимало 4 часа, а написание теста для него — от 8 до 16 часов.
Это косвенно указывает на качество кода. Использовать его так же сложно, а рефакторинг или расширение функциональности превращаются в кошмар.
SVZ>На другом проекте все еще хуже — данные плохо формализуются и написание тестов для автоматической проверки некоторых задач может потянуть на PhD. Поэтому проще сделать собственный отладчик и вручную проверять работу алгоритмов. Ну и ассерты помогают.
Если логику можно проверить вручную, то это можно сделать и автоматически. Не нужно пытаться получить общее решение с формализованными данными, для начала достаточно набора prerecorded data.
SVZ>В одном из срачей я уже приводил пример одной задачи — триангуляция 2Д объектов. Можно проверить, что внешний контур остался неизменным, а вот убедиться, что внутри не получилось каши — задачка не на 5 минут. Ее можно решить, но сложность ее гораздо выше, чем сам алгоритм триангуляции.
Для юнит теста не стоит задача проверить верность алгоритма, достаточно выбрать несколько заранее определенных ключевых сценариев (в данном случае форм объектов, для которых выполнение алгоритма пойдет по разным веткам) и убедиться, что алгоритм возвращает в целом непротиворечивый результат. Так чтобы действительно серьезный баг или поломка в результате рефакторинга обрушили тест. Небольшие, особо хитрые баги все еще будут проходить незамеченными, и это совершенно нормально. Каждый раз, когда такой баг будет обнаруживаться вы будете добавлять к тесту новый сценарий, покрывающий данную категорию объектов.
SVZ>И я так и не добился в тот раз ответа на вопрос, должны ли мы Тест обкладывать тестами?
Тесты для тестов — совершенно нормальная практика, к которой в конце концов приходит каждый, кто управляет большим набором тестов для достаточно сложного продукта. Первое приближение тестов для тестов — это использование моков. Мы подменяем реальный продукт его моком, который ломается в заранее известных местах, и проверяем, что тесты способны это выловить и не дать ложных срабатываний.
Здравствуйте, vb-develop, Вы писали:
VD>Если есть успешный опыт внедрения процесса написания тестов в проекте, тоже было бы интересно послушать.
Один из моих текущих проектов — VoIP свич — изначально был порождён без любых явных тестов на уровне кода и просуществовал в таком виде в течение приблизительно 5 лет, из которых 2 я был единственным разработчиком, а ещё один до того — вспомогательным. Тестирование проводилось отработкой конкретных сценариев вживую, с использованием соответствующей аппаратуры ("железные" телефоны и их аналоги).
Однако начиная с определённого уровня сложности стало слишком много наведённых эффектов, когда работы в одном месте стали ломать другие места. Объём кода тогда уже был очень существенным. Когда пригласили ещё одного человека и он начал шустро ломать работающее, я понял, что так дальше нельзя и лучше явно затормозить разработку, чем ломать релизы
Автоматизация тестирования началось с построения теста, который можно было бы по современным классификациям назвать чем-то средним между функциональным и интеграционным: создавалась среда, имитирующая рабочую, и участники — эмуляторы удалённых телефонов — прогоняли один звонок. Это было ничтожно мало, но начало было положено Я разметил пространство возможных тестов, пронумеровав его, и начал дальше покрывать разные случаи, по примерно следующему принципу:
1. Если на какое-то место выписан баг, то не закрывать тикет без нового теста, который бы этот баг опознал и стал удовлетворённым по результату фикса.
2. Все новые разработки покрываются тестами изначально (без этого старались не признавать разработку завершённой).
3. Если есть свободное время, то рисуется следующий тест в порядке убывания известной мне проблемности подсистемы/слоя/etc.
Конкретный вид теста рассматривался по обстановке, но предпочтение давалось максимально высокоуровневому в каждом случае, то есть тест на эмуляцию рабочей обстановки важнее теста для одного слоя, а тот — важнее, чем юнит-тест.
Потребовалось некоторое количество внушений коллегам, чтобы они проверяли сами результаты своего кодинга перед коммитом; к счастью, не было откровенно невменяемых участников, и двух-трёх случаев хватило на всех.
Потом я ушёл оттуда года на полтора, а когда вернулся — с новым руководителем всего подразделения разработки пришла и новая практика, включая переход на git вместо зоопарка CVS/SVN, использование ревью (gerrit) с автоконтролем существующих уже тестов (через Jenkins). Сейчас картина такова, что тесты покрывают около половины всех развилок и около 3/4 всего кода; и теперь меня уже агитируют делать как следует и рассказывают, как надо, а не наоборот Хотя в результате кросс-опыления идеями между работами туда пришла, например, идея инверсных тестов (и парочка таки сработала, когда надо).
Самым сложным в данном проекте обычно оказывается найти метод отвязаться от реальной обстановки и создать её адекватную эмуляцию для данной подзадачи. Очень много внешних связей, которые надо заглушить (ставятся заглушки всех мастей, от тупого запрета в конфиге до моков со сложным поведением).
VD>Мой вопрос был именно про написания тестов до появления багов, но после завершения отладки кода и выполнения задачи.
Тоже нужно, если видно, что новая функциональность уже не покрывается существующими тестами или появились какие-то новые use cases.
Тесты — самая лучшая документация. Кроме того, в будущем найдутся баги и нужно будет писать тесты до/после их исправления. Проще расширить существующий тест, чем писать новый с нуля. И отлаживать код по тестам проще.
Здравствуйте, vb-develop, Вы писали:
VD>Вторая тема, которую хотелось бы обсудить, это причины по которым разработчики не используют тесты для отладки кода. У меня есть некоторые размышления на этот счет, но хотелось бы послушать именно тех, кто не всегда пишет тесты и почему вы этого не делаете, что мешает начать писать.
В одном из проектов написание кода занимало 4 часа, а написание теста для него — от 8 до 16 часов. Как ты догадываешься, в таких условиях надо оооочень хотеть писать тесты.
На другом проекте все еще хуже — данные плохо формализуются и написание тестов для автоматической проверки некоторых задач может потянуть на PhD. Поэтому проще сделать собственный отладчик и вручную проверять работу алгоритмов. Ну и ассерты помогают.
_____________________
С уважением,
Stanislav V. Zudin
A>>Это косвенно указывает на качество кода. Использовать его так же сложно, а рефакторинг или расширение функциональности превращаются в кошмар. SVZ>Никуда это не указывает
Указывает-указывает. В коде все части сильно связаны между собой, сложно протестировать отдельный компонент в изоляции, компоненты требуют сложного сетапа/конфигурации прежде чем можно будет хотя бы создать объект и вызвать его метод. Поэтому юнит тесты пишутся со скрипом и на самом деле являются ориентированными на реализацию интеграционными тестами. Соответственно любое изменение проекта ведет к большим переделкам тестов. А проблема здесь в том, что проект изначально разрабатывался без тестов.
SVZ> Одно дело — протестировать какой-нибудь контейнер (что положил, то и взял), другое — какой-нибудь алгоритм, да еще асинхронный.
Протестировать можно все. Другое дело, что не все участки кода тестировать обязательно. Имея тесты вы всегда знаете качество каждого участка и можете принять решение о том, нужно ли добавлять тесты для данной области или нет. А без тестов вам остается только верить "вроде пока не падает, значит пока не сломали".
Здравствуйте, vb-develop, Вы писали:
VD>Если есть успешный опыт внедрения процесса написания тестов в проекте, тоже было бы интересно послушать.
Source control vertion плагин для 8 студии нехорошо сохраняет в SVN тесты, в результате тесты хранить вместе с проектом затруднительно, а это сильно мешает их использованию.
Здравствуйте, abibok, Вы писали:
SVZ>>В одном из проектов написание кода занимало 4 часа, а написание теста для него — от 8 до 16 часов.
A>Это косвенно указывает на качество кода. Использовать его так же сложно, а рефакторинг или расширение функциональности превращаются в кошмар.
Никуда это не указывает Одно дело — протестировать какой-нибудь контейнер (что положил, то и взял), другое — какой-нибудь алгоритм, да еще асинхронный.
Конкретно в этом случае был VoIP проект. Факт приема сигнала автоматически проверить можно. На слух оценить качество принимаемого сигнала тоже можно. Как оценить автоматически? Анализ спектра? Это может и не тянет на кандидатскую, но и за 5 минут не напишешь. А сложность теста будет такова, что на него придется писать собственные тесты
A>Если логику можно проверить вручную, то это можно сделать и автоматически. Не нужно пытаться получить общее решение с формализованными данными, для начала достаточно набора prerecorded data.
Мне "везет" работать с данными непредсказуемого качества.
Т.е. если следовать спецификации, использовать prerecorded данные, то все работает. А на реальных данных — хрен.
Поэтому у нас тесты применяются очень ограниченно. Больше используются run-time ассерты.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, abibok, Вы писали:
A>Тесты для тестов — совершенно нормальная практика, к которой в конце концов приходит каждый, кто управляет большим набором тестов для достаточно сложного продукта. Первое приближение тестов для тестов — это использование моков. Мы подменяем реальный продукт его моком, который ломается в заранее известных местах, и проверяем, что тесты способны это выловить и не дать ложных срабатываний.
Интересно, а собственно прикладной код вы писать успеваете? По скольку часов в неделю?
Не, если у вас mission critical — то без вопросов. В любом другом случае — бессмысленный overkill.
Здравствуйте, abibok, Вы писали:
A>Тесты для тестов — совершенно нормальная практика, к которой в конце концов приходит каждый, кто управляет большим набором тестов для достаточно сложного продукта. Первое приближение тестов для тестов — это использование моков. Мы подменяем реальный продукт его моком, который ломается в заранее известных местах, и проверяем, что тесты способны это выловить и не дать ложных срабатываний.
Собственно, в тесте уже прописано, на каких данных он должен падать, а на каких нет. Тест и тестируемый код тут в связке, и чтобы не заметить баг, надо внести взаимно-аннигилирующие правки и в код, и в тест, вероятность чего мизерна. Так что тесты для тестов — нафиг не нужны. А к использующим их у меня напрашивается естественный вопрос: а тесты для тестов для тестов и тесты для тестов для тестов для тестов у вас есть? И если нет, то почему.
Здравствуйте, netch80, Вы писали:
N>Второе — наша специфика, возможно, пригодна не всем, но у нас есть категория инверсных тестов. Например, мы знаем, что компонент 1, получив сигнал A, выдаёт B, а компонент 2 на его основе генерирует C. Не подав компоненту 1 на вход A, мы не можем получить на выходе C. Инверсный тест проверяет, что нарушение входных условий приводит к отрицательному общему выводу (С не получен). Это таки тестирование теста, а точнее, условий, лежащих в его основе.
Не понял, почему это тестирование теста. Насколько я понял, это точно такое же тестирвоание прикладного кода. Скажем, по входным данным (A,B,C) может быть сгенерирована пара тестов: A -> B -> C, !A -> !B -> !C. Оба теста — прикладные. Если же речь идёт про необходимость тестировать код, генерирующий эту самую пару тестов по входным наборам данных, то ИМХО это таки-оверкилл. Потому что вероятность появления описанной тобой ситуации:
>А вот представь себе, что тест уже написан, и он использует какой-нибудь специфический assertIsTrueWithContext(), и вот очередная переделка незаметно привела к тому, что этот вызов всегда успешен, что бы ни происходило
причём такой, чтобы в итоге все тесты успешно выполнялись, а не падали, мизерна. Хотя... если увлекаться тестированием сверху вниз, т.е. моками всякими, и вообще перегружать тестовый фреймворк винтиками — всякое возможно. Я всегда тестируюсь снизу вверх, у меня даже база настоящая, без моков (а точнее, несколько автоматически создаваемых баз по количеству параллельно выполняющихся тестов). Поэтому тестовый фреймворк предельно компактный, и ломаться там особо-то и нечему.
Здравствуйте, dimgel, Вы писали:
A>>Тесты для тестов — совершенно нормальная практика, к которой в конце концов приходит каждый, кто управляет большим набором тестов для достаточно сложного продукта. Первое приближение тестов для тестов — это использование моков. Мы подменяем реальный продукт его моком, который ломается в заранее известных местах, и проверяем, что тесты способны это выловить и не дать ложных срабатываний.
D>Собственно, в тесте уже прописано, на каких данных он должен падать, а на каких нет. Тест и тестируемый код тут в связке, и чтобы не заметить баг, надо внести взаимно-аннигилирующие правки и в код, и в тест, вероятность чего мизерна. Так что тесты для тестов — нафиг не нужны.
В процессе написания и при экспериментировании с ответами — да. А вот представь себе, что тест уже написан, и он использует какой-нибудь специфический assertIsTrueWithContext(), и вот очередная переделка незаметно привела к тому, что этот вызов всегда успешен, что бы ни происходило. Причём эта переделка происходит в коде, отстоящем от данного на несколько десятков каталогов. Вопрос — а как ты собственно это заметишь?
Поэтому первый тип "тестов на тесты" это тесты собственно тестовой инфраструктуры, если она сложнее того, что один человек может охватить взглядом за раз. Работоспособность тестовой инфраструктуры тоже должна быть подтверждена, и проверяться — на каждом запуске.
Второе — наша специфика, возможно, пригодна не всем, но у нас есть категория инверсных тестов. Например, мы знаем, что компонент 1, получив сигнал A, выдаёт B, а компонент 2 на его основе генерирует C. Не подав компоненту 1 на вход A, мы не можем получить на выходе C. Инверсный тест проверяет, что нарушение входных условий приводит к отрицательному общему выводу (С не получен). Это таки тестирование теста, а точнее, условий, лежащих в его основе. Для каждого теста продумывается набор таких точек, нарушение которых приводит к нарушению результата теста, и они записываются в список на проверку (например, в Makefile).
Пример коллеги abibok с моком — это такой же вариант, но с развитием событий не во времени, а в специфике взаимодействия компонент, и потому пригоден для класса задач, в которых временной фактор не играет принципиальной роли.
D> А к использующим их у меня напрашивается естественный вопрос: а тесты для тестов для тестов и тесты для тестов для тестов для тестов у вас есть? И если нет, то почему.
Потому что данного уровня в сочетании с ревью кода и живым QA пока что было достаточно.
Возможно, при выходе за какие-то безумные пределы размера и сложности потребовалось бы ещё что-то, не знаю, не сталкивался.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, AndreyM16, Вы писали:
AM>>В классификации изображений может и можно написать тесты, но это уже будут не юнит тесты(о которых изначально шла речь), а тесты качества классификатора. А вообще в области обработки изображений далеко не всегда можно(и имеет смысл) написать именно юнит тесты на какую-то часть определенного алгоритм.
M>На мой взгляд именно юнит тесты писать проще , но не всегда полезнее. Еще замечу , если возникают затруднения с тестированием функционала , это тревожный звоночек что разработка ушла не туда. Опять же с удовольствием послушаю конкретные примеры модулей тесты для которых реализовать сложно ( я верю что такие есть)
Ну я обычно всегда пытаюсь так разделить алгоритм, чтобы он состоял из отдельных нетривиальных простых функций, которые имеет смысл тестировать в силу их нетривиальности и модулей которые формируют параметры и вызывают эти функции в некоторой композиции(т.е. 2 уровня). Иногда нельзя обойтись без вспомогателного среднего нетривиального уровня, т.е. когда нетривиальные функции вызываются неким нетривиальным способом. Тестировать просто нетривиальную функцию не сложно, тестировать правильность последовательности вызова этих функций можно, но для этого нужно создать для них соответствующую DI инфраструктуру (или это интерфейсы, что может сказаться на производительности, или это темплейты, с чем можно просто задолбаться), при этом там все не сложно, поэтому этот слой я не тестирую. Тестирование среднего нетривиального слоя является проблемой. Вообще лучше делать лог со всего алгоритма на конкретных входных данных, проверять нужные критерии работы алгоритма(они могут быть различны для различных алгоритмов), а потом делать регрессионное тестирование.
Пример дать можно, но описывать его достаточно детально долго(С)Привет Ферма.
VD>Теперь о чем мой вопрос. А есть ли вообще смысл писать тесты после отладки кода?
Обязательно. Как правило на реальных проектах довольно хреново с покрытием кода тестами и вопрос о том, какой участок следует покрывать в первую очередь похож на вопрос "где проводить оптимизацию". Очень легко ошибиться и начать писать тесты не там, где они в данный момент нужны больше всего. Хорошим индикатором такого места являются баги — сломалось, починили, заодно и тесты написали. Обычно в процессе написания тестов выявляется еще два-три бага. В это время их удобно править, потому что все еще свежо в мозгах и легко не упустить никакие мелочи или побочные эффекты.
Здравствуйте, vb-develop, Вы писали:
VD>Одна из вещей, которая меня расстраивает на проекте: разработчики мало (относительно мало, относительно 100% покрытия) пишут тесты.
А какова твоя-то роль в проекте? Ты рядовой разработчик, или тимлид, или PM?
VD>Теперь о чем мой вопрос. А есть ли вообще смысл писать тесты после отладки кода?
Ну, задачи в жизни всякие встречаются. Бывают и такие задачи, в которых срок исполнения приоритетней, чем качество. Например, кровь из носу сделать такую-то фичу к такому-то числу, чтобы она более-менее сносно работала, а там посмотрим.
И в такой ситуации как раз уместно писать тесты после отладки. Например, сначала к жесткому дедлайну код написали, худо-бедно отладили, вроде бы оно работает и не падает. Но разработчика гложут сомнения: "а вдруг упадет?"
Вот тут хорошо бы было написать еще несколько тестов, проверить всякие исключительные случаи, про которые в запарке могли забыть. Лучше самому обнаружить багу и вовремя выпустить патчик, чем потом срочно выпускать патчик в ответ на гневную реакцию пользователей или заказчиков, неожиданно наткнувшихся на багу.
Здравствуйте, abibok, Вы писали:
A>Как отличить плохой тест от хорошего? Как узнать, не стал ли тест плохим при очередном изменении тестируемого кода? Как писать тесты без ошибок с первого захода?
Это тема кажется совсем другая.
A>Проверка контрактов включает в себя как позитивные, так и негативные тесты. Но говорим мы совсем не об этом. Все эти тесты применяются как к оригинальному продукту, так и к продукту с известными проблемами (что достигается путем моков или failure injection models). Плюс перемножение матриц — не очень удачный пример.
По моему великолепный пример, компактный, емкий , понятный. А вы так не уточнили , что подразумевали в изначальном посте под тестом теста.
A>Как бы вы управляли тестами реализации сетевого протокола? Можно услышать немного личного опыта вместо теоретических рассуждений?
Что вас конкретно интеревует , тема большая , много текста писать не хочется. Но вроде задача не рокет сайнс, никаких трудностей не вижу.
Работаю на большом проекте (длится несколько лет, всего занято 30-40 разработчиков, относительно высокая текучка). Проект — веб-приложение, по большому счету формоклепательство. Основные технологии: J2EE, Oracle, jQuery.
Одна из вещей, которая меня расстраивает на проекте: разработчики мало (относительно мало, относительно 100% покрытия) пишут тесты. Кто-то пишет от случая к случаю, кто-то не пишет вообще (еще и чужие выключают частенько, но речь не об этом).
Когда задаю вопрос, почему не написал тесты на новый код, часто слышу ответ: времени не было, собирался написать после выполнения задачи (т.е. когда код уже отлажен, закомичен и часто даже проверен тестировщиками). Для меня это очень странно, потому что у нас на проекте очень хорошая инфраструктура для тестов, их разработка тривиальна, не занимает много времени, ничего самому изобретать не надо, как правило. Я сам всегда пишу тесты для нового кода, мне так легче его проверить, чем собирать все приложение целиком, совершать телодвижения для проверки всего в интеграции. Но при этом я не пишу много тестов, не стремлюсь к полному покрытию, обычно это несколько смок-тестов и доп. проверки на хитрые случаи в зависимости от нетривиальности кода, своего рода баланс между временем на написание тестов и полнотой покрытия. Если требуется исправить ошибку, обычно сначала пишу тест, который локализует ошибку, затем исправляю код, и проверяю что тест проходит. В целом я считаю, что экономлю много времени уже на этом этапе, даже если забыть о пользе существования таких тестов на будущее (например, снижение риска переоткрытия ранее исправленных ошибок, что, к сожалению, на нашем проекте не редкость).
Теперь о чем мой вопрос. А есть ли вообще смысл писать тесты после отладки кода? Очевидный ответ да, ведь так будет больше шансов что функционал останется работоспособным в будущем, в него легче вносить изменения для меня несколько спорен. Во-первых, этот эффект проявится не сразу, а в каком-то туманном будущем. Во-вторых, вероятность что пользу почувствует именно автор, тоже далеко не 100%. С одной стороны это в перспективе демотивирует писать тесты, а с другой — снижает стимул писать именно хорошие, полезные тесты (да и сложнее отличить хорошие от плохих в этом случае) с большим покрытием. Ведь при отладке кода уже было исправлено много ошибок, если бы на каждую ошибку был написан тест, к завершению отладки мы бы получили пачку тестов, выявляющих проблемы, которые реально могут возникнуть.
Есть и другой момент в таком подходе. Когда пишешь тесты после выполнения задачи, к ним отношения как к некой дополнительной работе, которую можно делать, можно не делать, все равно никто проверять (тестировщики) не станут и по шее не дадут, как за ошибки. Забивание на тесты в данном случае это вполне объяснимое следствие. Но даже если тесты и будут написаны, это будет сделано через силу и вряд ли результат получится хорошего качества.
Третье возражение, это не смотря на всю простоту, поддержка и разработка тестов требуют каких-то затрат. Может оказаться что эти затраты никогда не отобьются. Заморозили фичу, удалили или полностью переделали заново, тоже не редкое явление. В случае разработки тестов до отладки кода, часть этих затрат (уверен, что в некоторых случаях эта часть превышает 100%) уже отбилась на этапе отладки. Поэтому возникает вопрос нужны ли вообще тесты, если речь идет не о разработке ядерного реактора и ценой ошибки можно пренебречь, если важнее эффективность в плане трудозатрат разработки.
Вторая тема, которую хотелось бы обсудить, это причины по которым разработчики не используют тесты для отладки кода. У меня есть некоторые размышления на этот счет, но хотелось бы послушать именно тех, кто не всегда пишет тесты и почему вы этого не делаете, что мешает начать писать.
Если есть успешный опыт внедрения процесса написания тестов в проекте, тоже было бы интересно послушать.
Здравствуйте, Vlad_SP, Вы писали:
V_S>Здравствуйте, vb-develop, Вы писали:
VD>>Одна из вещей, которая меня расстраивает на проекте: разработчики мало (относительно мало, относительно 100% покрытия) пишут тесты.
V_S>А какова твоя-то роль в проекте? Ты рядовой разработчик, или тимлид, или PM?
Очень интересно на что это влияет в плане обозначенной проблемы. При старте (недолго, до первой альфы) проекта был разработчиком, потом проект расширили и с тех пор работаю в роли тимлида.
Здравствуйте, abibok, Вы писали:
VD>>Теперь о чем мой вопрос. А есть ли вообще смысл писать тесты после отладки кода?
A>Обязательно. Как правило на реальных проектах довольно хреново с покрытием кода тестами и вопрос о том, какой участок следует покрывать в первую очередь похож на вопрос "где проводить оптимизацию". Очень легко ошибиться и начать писать тесты не там, где они в данный момент нужны больше всего. Хорошим индикатором такого места являются баги — сломалось, починили, заодно и тесты написали.
Я полностью поддерживаю такой подход При правке багов надо писать тесты, здесь у меня никаких сомнений. Мой вопрос был именно про написания тестов до появления багов, но после завершения отладки кода и выполнения задачи.
Здравствуйте, 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. Поэтому проще сделать собственный отладчик и вручную проверять работу алгоритмов. Ну и ассерты помогают.
Звучит странно. Даже в таких непростых областях как классификация изображений , тесты очень неплохо используются. поделитесь задачей
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>>На другом проекте все еще хуже — данные плохо формализуются и написание тестов для автоматической проверки некоторых задач может потянуть на PhD. Поэтому проще сделать собственный отладчик и вручную проверять работу алгоритмов. Ну и ассерты помогают.
M>Звучит странно. Даже в таких непростых областях как классификация изображений , тесты очень неплохо используются. поделитесь задачей
В одном из срачей я уже приводил пример одной задачи — триангуляция 2Д объектов. Можно проверить, что внешний контур остался неизменным, а вот убедиться, что внутри не получилось каши — задачка не на 5 минут. Ее можно решить, но сложность ее гораздо выше, чем сам алгоритм триангуляции.
И я так и не добился в тот раз ответа на вопрос, должны ли мы Тест обкладывать тестами?
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, abibok, Вы писали:
A>На практике угадывать с тестами — примерно то же самое, что угадывать с оптимизацией. На этапе проектирования можно разработать и test spec (не test plan), но бросаться писать абстрактные тесты того, чего еще нет даже в черновом варианте я бы не стал.
Тогда я не понимаю что вы имеете в виду, говоря "разработчики пишут юнит-тесты вместе с написанием кода". Значит всё-таки не "вместе" а "после", уже имея возможность оценить на что писать а на что — нет?
Y>Тогда я не понимаю что вы имеете в виду, говоря "разработчики пишут юнит-тесты вместе с написанием кода". Значит всё-таки не "вместе" а "после", уже имея возможность оценить на что писать а на что — нет?
Именно вместе, и даже немного раньше. Т.е. архитектура проекта разработана, функциональные спецификации написаны, а теперь TDD по полной программе — сначала тест, потом код. В момент написания теста "то что нужно тестировать" уже есть, просто оно еще не реализовано в коде.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>>И я так и не добился в тот раз ответа на вопрос, должны ли мы Тест обкладывать тестами?
M>Думаю нет, тест должен писаться так чтобы исключать повторение дублирующихся ошибок (в тесте и коде)
Мне тоже кажется, что нет. Все-таки тест должен быть достаточно простым.
После ответа abibok'а
обдумал еще раз задачу с триангуляцией, получается, что единственное решение в таком случае — по мере обработки реальных данных накапливать базу примеров и правильных решений к ним (эталоны). И проверять не корректность алгоритма, а сравнивать полученный результат с эталонным, буквально побайтно.
Т.е. фактически будет один тест, к нему много входных данных с готовыми результатами, которые будут пополняться по мере появления реальных данных.
_____________________
С уважением,
Stanislav V. Zudin
обдумал еще раз задачу с триангуляцией, получается, что единственное решение в таком случае — по мере обработки реальных данных накапливать базу примеров и правильных решений к ним (эталоны). И проверять не корректность алгоритма, а сравнивать полученный результат с эталонным, буквально побайтно.
Можно и так, это довольно дубовый подход, но для некоторых классов алгоритмов сработает отлично. Хотя будьте готовы к тому, что небольшое изменение требований и функциональной спецификации будет приводить к необходимости переделывать базу. Это черный ящик. А белый ящик — это понять как работает алгоритм и какие у него есть ветки исполнения, а потом для каждой ветки придумать тест. Плюс алгоритм — это не монолит из десяти тысяч строк кода, а набор более примитивных функций, каждая из которых может быть протестирована в изоляции или замокана.
M>Думаю нет, тест должен писаться так чтобы исключать повторение дублирующихся ошибок (в тесте и коде)
Тест может не работать вообще, из-за бага или из-за неполного покрытия, и всегда проходить. Как вы распознаете такую ситуацию? Как минимум, нужны негативные тесты.
Здравствуйте, abibok, Вы писали:
M>>Думаю нет, тест должен писаться так чтобы исключать повторение дублирующихся ошибок (в тесте и коде)
A>Тест может не работать вообще, из-за бага или из-за неполного покрытия, и всегда проходить. Как вы распознаете такую ситуацию?
Надо правильно организовывать тест. Что это за тест такой который всегда проходит , что он проверяет ?
A> Как минимум, нужны негативные тесты.
Нужны если нужны , простите за тавтологию. Например тест перемножения матриц, пустить данные и несоответствующий результат и проверить что они ТАКИ да несоответствуют друг другу, зачем ? Ну и т.д.
A>>Тест может не работать вообще, из-за бага или из-за неполного покрытия, и всегда проходить. Как вы распознаете такую ситуацию? M>Надо правильно организовывать тест. Что это за тест такой который всегда проходит , что он проверяет ?
Читайте строчкой выше. Автор теста предполагал, что тест будет проверять некоторый аспект модели. На практике оказалось, что реализация отличается от модели, а в самом тесте был баг, или просто тест был недостаточно сложен, чтобы распознать ошибку — и проходил.
A>> Как минимум, нужны негативные тесты. M> Нужны если нужны , простите за тавтологию. Например тест перемножения матриц, пустить данные и несоответствующий результат и проверить что они ТАКИ да несоответствуют друг другу, зачем ?
Для перемножения матриц было бы неплохо определить ожидаемое поведение и проверить его тестами в таких случаях:
1) Размеры матриц не совпадают.
2) Одна из матриц (или обе) пусты.
3) Единичные и нулевые матрицы.
4) Сильно разреженные матрицы.
5) Перемножить матрицу и обратную ей матрицу.
6) Матрицы так велики, что результат не поместится в памяти.
7) Матрицы так велики, что перемножение займет слишком много времени.
8) Arithmetic overflow или underflow при перемножении.
А потом надеть шляпу исследователя белых ящиков и понять, что в тестируемом алгоритме реализован метод Штрассена. И добавить еще столько же интересных тестов.
Здравствуйте, abibok, Вы писали:
A>Читайте строчкой выше. Автор теста предполагал, что тест будет проверять некоторый аспект модели. На практике оказалось, что реализация отличается от модели, а в самом тесте был баг, или просто тест был недостаточно сложен, чтобы распознать ошибку — и проходил.
Это плохой тест, если проверять тест с таким же качеством то и результат будет опять не очень. Т.е. результат будет лучше от качества теста а не от количества.
A>Для перемножения матриц было бы неплохо определить ожидаемое поведение и проверить его тестами в таких случаях:
...
Ок, если проверку контрактов называть негативными тестатми тогда нет возражений. Но из контекста беседы я думал о другом, о тесте теста который валится от неправильной работы основного кода
M>Это плохой тест, если проверять тест с таким же качеством то и результат будет опять не очень.
Как отличить плохой тест от хорошего? Как узнать, не стал ли тест плохим при очередном изменении тестируемого кода? Как писать тесты без ошибок с первого захода?
M>Т.е. результат будет лучше от качества теста а не от количества.
Боюсь вы не понимаете о чем говорите.
M>Ок, если проверку контрактов называть негативными тестатми тогда нет возражений. Но из контекста беседы я думал о другом, о тесте теста который валится от неправильной работы основного кода
Проверка контрактов включает в себя как позитивные, так и негативные тесты. Но говорим мы совсем не об этом. Все эти тесты применяются как к оригинальному продукту, так и к продукту с известными проблемами (что достигается путем моков или failure injection models). Плюс перемножение матриц — не очень удачный пример. Как бы вы управляли тестами реализации сетевого протокола? Можно услышать немного личного опыта вместо теоретических рассуждений?
Здравствуйте, dimgel, Вы писали:
N>>Второе — наша специфика, возможно, пригодна не всем, но у нас есть категория инверсных тестов. Например, мы знаем, что компонент 1, получив сигнал A, выдаёт B, а компонент 2 на его основе генерирует C. Не подав компоненту 1 на вход A, мы не можем получить на выходе C. Инверсный тест проверяет, что нарушение входных условий приводит к отрицательному общему выводу (С не получен). Это таки тестирование теста, а точнее, условий, лежащих в его основе.
D>Не понял, почему это тестирование теста. Насколько я понял, это точно такое же тестирвоание прикладного кода. Скажем, по входным данным (A,B,C) может быть сгенерирована пара тестов: A -> B -> C, !A -> !B -> !C.
НЕТ. В том и дело, что я не делаю такой тест. Я делаю тест, что на входе A, на выходе C. Потом я добавляю к нему вариацию (например, на входе не подано A) и я не проверяю явно, что нет C; нет, я проверяю уровнем выше, что проверка на C сломалась и соответственно тест сказал "фигня, у вас нет C".
А ещё лучше нарисовать следующим примером: в инверсии даже не меняем основной код теста, но меняем внутреннюю логику системы и она из B делает не C, а D. И опять-таки тест должен сказать "караул! я хотел C, а пришло какое-то D!" Вот по этому сообщению от теста и проверяется, что он работает. Или как минимум по факту отказа теста, если облом делать глубокую проверку.
А твой вариант не работает потому, что он разрешает после написания кода написать любую фигню, лишь бы она ответила "да, работает". Что она проверяет и как — неизвестно, потому что реальная проверка может быть закручена на 20-й уровень шаблонизации и абстракции, и никто с этим не будет разбираться во всех деталях. Нет, проверка такого рода может быть только снаружи от собственно кода, выполняющего тест, и проверяться именно на том, что если задать условие, которое должно быть нарушено, то тест опознаёт это.
D> Оба теста — прикладные. Если же речь идёт про необходимость тестировать код, генерирующий эту самую пару тестов по входным наборам данных, то ИМХО это таки-оверкилл. Потому что вероятность появления описанной тобой ситуации:
>>А вот представь себе, что тест уже написан, и он использует какой-нибудь специфический assertIsTrueWithContext(), и вот очередная переделка незаметно привела к тому, что этот вызов всегда успешен, что бы ни происходило
D>причём такой, чтобы в итоге все тесты успешно выполнялись, а не падали, мизерна.
Именно такой — возможно, и мизерна. Но на практике у меня были случаи, когда проблема ловилась именно инверсией тестов. Это были очень глубинные проблемы, такие, что писать на них прямые тесты было крайне сложно.
D> Хотя... если увлекаться тестированием сверху вниз, т.е. моками всякими, и вообще перегружать тестовый фреймворк винтиками — всякое возможно. Я всегда тестируюсь снизу вверх, у меня даже база настоящая, без моков (а точнее, несколько автоматически создаваемых баз по количеству параллельно выполняющихся тестов). Поэтому тестовый фреймворк предельно компактный, и ломаться там особо-то и нечему.
Если бы ещё было понятно, что такое "сверху вниз" в данном контексте...
Здравствуйте, netch80, Вы писали:
N>А ещё лучше нарисовать следующим примером: в инверсии даже не меняем основной код теста, но меняем внутреннюю логику системы и она из B делает не C, а D.
Так вроде бы понял. Но мне едва ли, надеюсь, когда-либо придётся докатываться до такого.
N>Если бы ещё было понятно, что такое "сверху вниз" в данном контексте...
Myers "The art of software testing" 2nd edition. В двух словах: тестирование сверху вниз следует за разработкой сверху вниз. Т.е. когда у нас сначала есть только морда лица с заглушками вместо функционала, чтобы быстро показать заказчику, мы и тестировать её вынуждены с заглушками — теми же или другими (моками). А если мы разрабатываем снизу вверх, то нам не нужны ни заглушки вместо функционала, ни моки в тестах: просто тесты всех слоёв кроме самых нижних по сути становятся интеграционными. Это он называет тестированием снизу вверх. И сравнение плюсов и минусов обоих подходов, которое он приводит, полностью соответствовало моему собственному мироощущению: достоинство у "сверху вниз" по сути только одно: можно быстро что-то показать заказчику. А недостаток — лишняя работа на поддержание моков. Т.е. тактический выигрыш и стратегический проигрыш. По мере наращивания функционала в нижележащих слоях он, впрочем, ЕМНИП точно также избавляется от моков, заменяя их реальным кодом с заглушками в ещё нереализованных зависимостях на более нижних слоях. Поскольку я сам никогда не парюсь с "быстро показать", то всегда и разрабатываю снизу вверх, и не трачу время на моки. В итоге суммарно выигрываю, и если работодатель один раз вытерпел моё долгое копошение без промежуточных результатов и в конце концов увидел вдруг всё и сразу ("м-да, впечатляет" (c)), больше у него к такой манере разработки претензий не остаётся. А если ему терпения не хватило — ну и чёрт с ним.
Здравствуйте, dimgel, Вы писали:
N>>А ещё лучше нарисовать следующим примером: в инверсии даже не меняем основной код теста, но меняем внутреннюю логику системы и она из B делает не C, а D. D>Так вроде бы понял. Но мне едва ли, надеюсь, когда-либо придётся докатываться до такого.
Ну хум хау. У меня это оказалось предельно естественным подходом по нескольким причинам. Во-первых, софт целился на суровый mission critical (потом смягчили, но ряд заточек остался), отсюда некоторые другие интересные моменты: например, на той же системе впараллель отрабатывается фиктивная установка, на которой сверяются реакции, включая критические случаи. Во-вторых, часть коллектива — бывшие вояки, так что заточка шла и на принятые там методы. В целом результат мне понравился
N>>Если бы ещё было понятно, что такое "сверху вниз" в данном контексте...
D>Myers "The art of software testing" 2nd edition. В двух словах: тестирование сверху вниз следует за разработкой сверху вниз. Т.е. когда у нас сначала есть только морда лица с заглушками вместо функционала, чтобы быстро показать заказчику, мы и тестировать её вынуждены с заглушками — теми же или другими (моками). А если мы разрабатываем снизу вверх, то нам не нужны ни заглушки вместо функционала, ни моки в тестах: просто тесты всех слоёв кроме самых нижних по сути становятся интеграционными.
Свежо предание, но верится с трудом. Во-первых, разработка снизу вверх сама по себе проблемна тем, что приводит к излишней разработке тех требований, которые могут никогда в реальности не пригодиться. Типа, нам нужна работа со строками — сделаем там всё от и до, включая поиск мегабайтной строки в терабайтном файле А в реальности нужно искать в памяти в объёме, влезающем в L1. Во-вторых, стыки с соседними функциональными блоками всё равно разрабатываются под некоторую функциональность этих блоков, отсюда возникают моки. Извини, я не могу себе представить крупную задачу, в которой можно настолько раздельно тестировать все слои и подсистемы...
D> Это он называет тестированием снизу вверх. И сравнение плюсов и минусов обоих подходов, которое он приводит, полностью соответствовало моему собственному мироощущению: достоинство у "сверху вниз" по сути только одно: можно быстро что-то показать заказчику.
Вопрос же не только в "показать заказчику", вопрос в понимании всех участников — от заказчика до последнего кодера — что же они делают, почему, что сделано правильно, а что — нет.
Разработка снизу вверх годится только в том случае, когда функционал заранее уже безошибочно продуман на всех уровнях, и требования не будут меняться за время разработки. То есть в реальности — в ничтожной доле случаев, если не в нулевой.
D> А недостаток — лишняя работа на поддержание моков. Т.е. тактический выигрыш и стратегический проигрыш.
Строго наоборот Небольшой тактический проигрыш на написание мока сопровождается глобальным стратегическим выигрышем на построение ровно того, что надо, и обеспечение реального контроля этого функционала.
D> По мере наращивания функционала в нижележащих слоях он, впрочем, ЕМНИП точно также избавляется от моков, заменяя их реальным кодом с заглушками в ещё нереализованных зависимостях на более нижних слоях. Поскольку я сам никогда не парюсь с "быстро показать", то всегда и разрабатываю снизу вверх, и не трачу время на моки. В итоге суммарно выигрываю, и если работодатель один раз вытерпел моё долгое копошение без промежуточных результатов и в конце концов увидел вдруг всё и сразу ("м-да, впечатляет" (c)), больше у него к такой манере разработки претензий не остаётся. А если ему терпения не хватило — ну и чёрт с ним.
Особенно последнее предложение радует Но я всё-таки не могу понять, для каких задач работает такой подход. У меня таких задач нет.
Здравствуйте, netch80, Вы писали:
N>Свежо предание, но верится с трудом. Во-первых, разработка снизу вверх сама по себе проблемна тем, что приводит к излишней разработке тех требований, которые могут никогда в реальности не пригодиться. Типа, нам нужна работа со строками — сделаем там всё от и до, включая поиск мегабайтной строки в терабайтном файле А в реальности нужно искать в памяти в объёме, влезающем в L1.
Никто в здравом уме "всё от и до" делать не будет. Пишется совершенно конкретный каркас с минимальным функционалом, достаточным, чтобы начать работать над вышележащим слоем. И так далее. Когда доходим доверху, начинаем расширять функционал сразу на всех слоях. Т.е. программа растёт не сверху вниз, а вширь. Общий же план в общих чертах имеется с самого начала: как говорил товарищ Страуструп, это очень неплохая идея — прежде чем бросаться писать что-либо, сесть и подумать, что же именно ты хочешь написать. Не путать этот общий взгляд с детальным планированием "сверху вниз".
N>Во-вторых, стыки с соседними функциональными блоками всё равно разрабатываются под некоторую функциональность этих блоков, отсюда возникают моки. Извини, я не могу себе представить крупную задачу, в которой можно настолько раздельно тестировать все слои и подсистемы...
Раздельное тестирование — это как раз про "сверху вниз", при "снизу вверх" оно не раздельное, я ж написал: все тесты по сути интеграционные.
N>Вопрос же не только в "показать заказчику", вопрос в понимании всех участников — от заказчика до последнего кодера — что же они делают, почему, что сделано правильно, а что — нет.
Представление программы в головах программистов очень сильно отличается от оной в головах заказчиков. См. "не будите программиста".
N>Разработка снизу вверх годится только в том случае, когда функционал заранее уже безошибочно продуман на всех уровнях, и требования не будут меняться за время разработки.
До сих пор я слышал о "заранее продуманном на всех уровнях" функционале исключительно в контексте водопадной модели, как раз-таки "сверху вниз". Ты всё поставил с ног на голову.
N>Строго наоборот Небольшой тактический проигрыш на написание мока
И незабывание поддержания его поведения согласованным с изменяющимся поведением системы. Впрочем, если у тебя "сверху вниз" и всё поведение заранее продумано и гвоздями прибито...
N>сопровождается глобальным стратегическим выигрышем на построение ровно того, что надо, и обеспечение реального контроля этого функционала.
При "снизу вверх", как я выше описал, я точно также строю ровно то, что надо, и не граммом больше.
Здравствуйте, dimgel, Вы писали:
N>>Свежо предание, но верится с трудом. Во-первых, разработка снизу вверх сама по себе проблемна тем, что приводит к излишней разработке тех требований, которые могут никогда в реальности не пригодиться. Типа, нам нужна работа со строками — сделаем там всё от и до, включая поиск мегабайтной строки в терабайтном файле А в реальности нужно искать в памяти в объёме, влезающем в L1. D>Никто в здравом уме "всё от и до" делать не будет. Пишется совершенно конкретный каркас с минимальным функционалом, достаточным, чтобы начать работать над вышележащим слоем. И так далее. Когда доходим доверху, начинаем расширять функционал сразу на всех слоях. Т.е. программа растёт не сверху вниз, а вширь. Общий же план в общих чертах имеется с самого начала: как говорил товарищ Страуструп, это очень неплохая идея — прежде чем бросаться писать что-либо, сесть и подумать, что же именно ты хочешь написать. Не путать этот общий взгляд с детальным планированием "сверху вниз".
Хорошо. Пусть ты пишешь "каркас" с "минимальным функционалом" который "достаточен"... стоп. Кто определяет, что он достаточен, и на основании чего? Я вижу единственное объяснение — предварительно пройдена (может быть, в голове, не на бумаге; частично даже подсознательно) работа по проектированию, которая включает в себя 1) оформление логических объектов, 2) определение функционала и API.
То есть это всё то же самое "сверху вниз", но скрытое. А то, что ты дальше рассказываешь — итерации разработки под уточнения ТЗ.
Чистое "снизу вверх" было бы только в том случае, когда, как писали классики,
Другой юноша нес свое: "Я нашел, как применить здесь нестирающиеся шины из полиструктурного волокна с вырожденными аминными связями и неполными кислородными группами. Но я не знаю пока, как использовать регенерирующий реактор на субтепловых нейтронах. Миша, Мишок! Как быть с реактором?" Присмотревшись к устройству, я без труда узнал велосипед.
Если бы задача стояла — применить конкретную технологию несмотря ни на что, независимо от уровня её адекватности задаче — это было бы "снизу вверх" в чистом виде. Но, я надеюсь, в IT (у вменяемых) такого нет. (Разумный уровень legacy я не считаю плохим, но надо понимать, когда он стаёт неразумным.) А то, что мы видим — это оформление базовых требований "сверху вниз" и далее подстановка готового (пусть даже мысленно) из того, что ориентировочно подходит под эти требования.
А то, что часто дальше можно думать только имея "минимальный каркас" и вызывая feedback'и всех участников — очевидно каждому, кто учил ребёнка арифметике Но привычка начинать этот каркас снизу, а не сверху — плохая привычка, потому что ведёт к слишком шаблонным решениям и неучёту реальных требований.
N>>Во-вторых, стыки с соседними функциональными блоками всё равно разрабатываются под некоторую функциональность этих блоков, отсюда возникают моки. Извини, я не могу себе представить крупную задачу, в которой можно настолько раздельно тестировать все слои и подсистемы... D>Раздельное тестирование — это как раз про "сверху вниз", при "снизу вверх" оно не раздельное, я ж написал: все тесты по сути интеграционные.
Нет. К интеграционным тестам можно переходить только тогда, когда нижние слои оттестированы, так? Если нет, то ты опять объясняешь так, что изначально ни фига не понятно. А если да, то это и есть раздельное тестирование.
N>>Вопрос же не только в "показать заказчику", вопрос в понимании всех участников — от заказчика до последнего кодера — что же они делают, почему, что сделано правильно, а что — нет. D>Представление программы в головах программистов очень сильно отличается от оной в головах заказчиков. См. "не будите программиста".
Да даже два программиста за соседними столами будут видеть программу по-разному. И что? Мы сейчас обсуждаем совсем не этот фактор. Важно не то, что кто-то что-то себе "представляет", "видит", все мы художники, только большинство не тренированные. Важно то, что участник в конце концов в состоянии высказать и в надлежащих терминах.
N>>Разработка снизу вверх годится только в том случае, когда функционал заранее уже безошибочно продуман на всех уровнях, и требования не будут меняться за время разработки. D>До сих пор я слышал о "заранее продуманном на всех уровнях" функционале исключительно в контексте водопадной модели, как раз-таки "сверху вниз". Ты всё поставил с ног на голову.
Я как раз вернул всё на свои места и в свои правильные позиции Термин "водопадная модель" слишком часто трактуют неправильно. В нём важно не то, что сверху вниз, а то, что безвозвратно, безостановочно (вода уже падает) и один раз. Спроектировали — и никаких изменений на верхнем уровне, пока не будет закончена реализация. Так вот — именно в этом случае, таки да, после формулирования ТЗ всех уровней годится (но не является единственной!) разработка снизу вверх — просто потому, что уже неважно, в каком порядке разрабатывать
N>>Строго наоборот Небольшой тактический проигрыш на написание мока D>И незабывание поддержания его поведения согласованным с изменяющимся поведением системы. Впрочем, если у тебя "сверху вниз" и всё поведение заранее продумано и гвоздями прибито...
Неверное и некорректное допущение.
N>>сопровождается глобальным стратегическим выигрышем на построение ровно того, что надо, и обеспечение реального контроля этого функционала.
D>При "снизу вверх", как я выше описал, я точно также строю ровно то, что надо, и не граммом больше.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, Stanislav V. Zudin, Вы писали:
M>Звучит странно. Даже в таких непростых областях как классификация изображений , тесты очень неплохо используются. поделитесь задачей
В классификации изображений может и можно написать тесты, но это уже будут не юнит тесты(о которых изначально шла речь), а тесты качества классификатора. А вообще в области обработки изображений далеко не всегда можно(и имеет смысл) написать именно юнит тесты на какую-то часть определенного алгоритм.
Здравствуйте, AndreyM16, Вы писали:
AM>В классификации изображений может и можно написать тесты, но это уже будут не юнит тесты(о которых изначально шла речь), а тесты качества классификатора. А вообще в области обработки изображений далеко не всегда можно(и имеет смысл) написать именно юнит тесты на какую-то часть определенного алгоритм.
На мой взгляд именно юнит тесты писать проще , но не всегда полезнее. Еще замечу , если возникают затруднения с тестированием функционала , это тревожный звоночек что разработка ушла не туда. Опять же с удовольствием послушаю конкретные примеры модулей тесты для которых реализовать сложно ( я верю что такие есть)
Здравствуйте, netch80, Вы писали:
N>Самым сложным в данном проекте обычно оказывается найти метод отвязаться от реальной обстановки и создать её адекватную эмуляцию для данной подзадачи. Очень много внешних связей, которые надо заглушить (ставятся заглушки всех мастей, от тупого запрета в конфиге до моков со сложным поведением).
Кстати рекомендую обратить внимание на runtime verification практики , которые ну очень сильно упрощают тестирование именно в сложном окружении.
Здравствуйте, netch80, Вы писали, а я чёт пропустил видимо письмо с ответом:
N>Хорошо. Пусть ты пишешь "каркас" с "минимальным функционалом" который "достаточен"... стоп. Кто определяет, что он достаточен, и на основании чего? Я вижу единственное объяснение — предварительно пройдена (может быть, в голове, не на бумаге; частично даже подсознательно) работа по проектированию, которая включает в себя 1) оформление логических объектов, 2) определение функционала и API. N>То есть это всё то же самое "сверху вниз", но скрытое. А то, что ты дальше рассказываешь — итерации разработки под уточнения ТЗ.
Да, так и есть. Прикидываю все слои сверху до низу-минус-один и кладу их в голове на стек. Не так сложно, учитывая, что в вебе-энтерпрайзе этих слоёв — раз, два и обчёлся, да и типовые они все. "Левой пишешь — правой дрочишь" (c) пост в usenet про написание под копирку складских программ в до-1C-овскую эру. Так что на данный момент у меня вообще два слоя: фреймворковый и прикладной, и творчество заключается только в фигурном выпиливании фреймворкового слоя, т.к. прикладной скушный донельзя, даже если предметные области разные и незнакомые: формоклёпство сплошное.
N>Но привычка начинать этот каркас снизу, а не сверху — плохая привычка, потому что ведёт к слишком шаблонным решениям и неучёту реальных требований.
Ну, "реальные требования" это самая загадочная и аморфная вещь во Вселенной, так что я по ней никогда не заморачиваюсь. Статика + "агрессивный рефакторинг" (как тут недавно рекомендовали) рулят.
N>Нет. К интеграционным тестам можно переходить только тогда, когда нижние слои оттестированы, так? Если нет, то ты опять объясняешь так, что изначально ни фига не понятно. А если да, то это и есть раздельное тестирование.
Ну да, тесты для нижнего слоя тестируют только нижний слой, т.к. что ещё они могут тестировать? А вот тесты всех остальных слоёв всегда являются интеграционными и тестируют всё сразу, термин "раздельное" тут звучит как-то странно.
N>Я как раз вернул всё на свои места и в свои правильные позиции Термин "водопадная модель" слишком часто трактуют неправильно. В нём важно не то, что сверху вниз, а то, что безвозвратно, безостановочно (вода уже падает) и один раз. Спроектировали — и никаких изменений на верхнем уровне, пока не будет закончена реализация. Так вот — именно в этом случае, таки да, после формулирования ТЗ всех уровней годится (но не является единственной!) разработка снизу вверх — просто потому, что уже неважно, в каком порядке разрабатывать
Кошмар. Это из какой-то идеальной вселенной, где и заказчику ничего в голову не может взбрести по дороге, и исполнители все как один гений на гении и никогда не вляпываются в "гладко было на бумаге". Не, в какой-нибудь военке или космонавтике это может и единственно верный подход. Но не такой уж большой процент программистов работают на военку и космонавтику.
N>>>Строго наоборот Небольшой тактический проигрыш на написание мока D>>И незабывание поддержания его поведения согласованным с изменяющимся поведением системы. Впрочем, если у тебя "сверху вниз" и всё поведение заранее продумано и гвоздями прибито...
N>Неверное и некорректное допущение.
Где именно? Ты ж только что сам выше разжевал про водопадную модель, что гвоздями прибито "безвозвратно".
D>>При "снизу вверх", как я выше описал, я точно также строю ровно то, что надо, и не граммом больше.
N>Потому что ты уже прошёлся сверху вниз мысленно.
Ага. Очень быстро прошёлся, практически без затрат времени. И избавил себя от затрат времени на моки всякие.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Никуда это не указывает Одно дело — протестировать какой-нибудь контейнер (что положил, то и взял), другое — какой-нибудь алгоритм, да еще асинхронный.
Асинхронность — это state machine. В чём проблема прогнать её по всем осмысленным комбинациям состояний? Повторюсь, по осмысленным комбинациям (а то сейчас набегут про комбинаторный взрыв рассказывать).
SVZ>Конкретно в этом случае был VoIP проект. Факт приема сигнала автоматически проверить можно. На слух оценить качество принимаемого сигнала тоже можно. Как оценить автоматически? Анализ спектра? Это может и не тянет на кандидатскую, но и за 5 минут не напишешь. А сложность теста будет такова, что на него придется писать собственные тесты
Тут смешались в кучу тесты интеграционные и юнит-тесты.
Интеграционный — строим "боевую" инфраструктуру, запускаем сценарий приёма-передачи, проверяем логи обоих сторон, выносим вердикт: passed/failed.
Юнит-тест: положили тестируемый код в sandbox, все внешние зависимости заменены на мок-заглушки, имеющие строго предопределённые результаты (возвращаем известный дамп сигнала), дёргаем тестируемый метод обсчёта качества, сверяем с ожидаемым результатом. При необходимости, можно прогнать N характерных дампов и получить N результатов, сравнить с ожидаемыми N результатами.
Т.е. юнит-тесты — первый рубеж проверок в сандбоксе. Затем постепенно заменяем части сандбокса на свой код и тестируем интеграцию кусков между собой. Да, это дофига "лишней" работы. Но почему-то строители используют дофига лишних приспособлений (леса, лебёдки и т.п.) которые затем всё равно не используются жильцами дома...
Здравствуйте, netch80, Вы писали:
N>Потом я ушёл оттуда года на полтора, а когда вернулся — с новым руководителем всего подразделения разработки пришла и новая практика, включая переход на git вместо зоопарка CVS/SVN, использование ревью (gerrit) с автоконтролем существующих уже тестов (через Jenkins). Сейчас картина такова, что тесты покрывают около половины всех развилок и около 3/4 всего кода; и теперь меня уже агитируют делать как следует и рассказывают, как надо, а не наоборот
Помогли ли все эти прелести жизни? Стал ли существенно лучше продукт? Упростился (или удешевился) ли процесс разработки?
Здравствуйте, Mиxa, Вы писали:
N>>Потом я ушёл оттуда года на полтора, а когда вернулся — с новым руководителем всего подразделения разработки пришла и новая практика, включая переход на git вместо зоопарка CVS/SVN, использование ревью (gerrit) с автоконтролем существующих уже тестов (через Jenkins). Сейчас картина такова, что тесты покрывают около половины всех развилок и около 3/4 всего кода; и теперь меня уже агитируют делать как следует и рассказывают, как надо, а не наоборот
M>Помогли ли все эти прелести жизни?
Да.
M> Стал ли существенно лучше продукт?
Стало значительно меньше проблем, которые ловятся не разработчиками, а QC и далее в production.
М> Упростился (или удешевился) ли процесс разработки?
Да. Более ранний отлов явных багов, существенное упрощение совместной разработки за счёт меньшего количества конфликтов изменений, упрощение поддержки параллельных веток, и так далее.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Тут смешались в кучу тесты интеграционные и юнит-тесты. MD>Интеграционный — строим "боевую" инфраструктуру, запускаем сценарий приёма-передачи, проверяем логи обоих сторон, выносим вердикт: passed/failed. MD>Юнит-тест: положили тестируемый код в sandbox, все внешние зависимости заменены на мок-заглушки, имеющие строго предопределённые результаты (возвращаем известный дамп сигнала), дёргаем тестируемый метод обсчёта качества, сверяем с ожидаемым результатом. При необходимости, можно прогнать N характерных дампов и получить N результатов, сравнить с ожидаемыми N результатами.
Не "смешались в кучу", а часто невозможно провести разделение, потому что то, что юнит-тест для уровня 4, будет интеграционным для уровня 2. И эмуляция какой-то части "боевой" инфраструктуры в sandbox'е, по Вашей терминологии — штатная ситуация.
Но это не спасает напрямую от проблем тестирования в действительно реальном окружении, когда начинают вмешиваться неизвестные факторы.
MD>Т.е. юнит-тесты — первый рубеж проверок в сандбоксе. Затем постепенно заменяем части сандбокса на свой код и тестируем интеграцию кусков между собой. Да, это дофига "лишней" работы. Но почему-то строители используют дофига лишних приспособлений (леса, лебёдки и т.п.) которые затем всё равно не используются жильцами дома...
Это понятно, но описанным проблемам это не поможет.
Здравствуйте, dimgel, Вы писали:
D>Да, так и есть. Прикидываю все слои сверху до низу-минус-один и кладу их в голове на стек. Не так сложно, учитывая, что в вебе-энтерпрайзе этих слоёв — раз, два и обчёлся, да и типовые они все. "Левой пишешь — правой дрочишь" (c) пост в usenet про написание под копирку складских программ в до-1C-овскую эру. Так что на данный момент у меня вообще два слоя: фреймворковый и прикладной, и творчество заключается только в фигурном выпиливании фреймворкового слоя, т.к. прикладной скушный донельзя, даже если предметные области разные и незнакомые: формоклёпство сплошное.
Ну, видимо, в этом и есть основное различие прикладных областей, которое приводит к разнице подходов. Потому что у меня невозможно всё сократить в один слой, реально их с полдесятка набирается с ходу, а если глубоко анализировать, то там и вся дюжина И построение архитектуры с первого раза — нереальная фантастика. Потому и требуются методы, которые позволяют перестройку на ходу малой кровью.
N>>Нет. К интеграционным тестам можно переходить только тогда, когда нижние слои оттестированы, так? Если нет, то ты опять объясняешь так, что изначально ни фига не понятно. А если да, то это и есть раздельное тестирование. D>Ну да, тесты для нижнего слоя тестируют только нижний слой, т.к. что ещё они могут тестировать? А вот тесты всех остальных слоёв всегда являются интеграционными и тестируют всё сразу, термин "раздельное" тут звучит как-то странно.
Во-во. Потому я обычно и говорю, что разделение на юнит-тесты, функциональные и интеграционные — чистая искусственность. Есть функциональное тестирование, которое производится с блоками разного размера и слоистости. Конечно, что-то из верхнего уровня можно и нужно скрестить с заглушками и моками нижнего уровня, но часто этого даже нельзя делать, если хочешь получить честный результат. Например, менять какую-нибудь strcmp() бессмысленно, даже если ты её сам написал
N>>Я как раз вернул всё на свои места и в свои правильные позиции Термин "водопадная модель" слишком часто трактуют неправильно. В нём важно не то, что сверху вниз, а то, что безвозвратно, безостановочно (вода уже падает) и один раз. Спроектировали — и никаких изменений на верхнем уровне, пока не будет закончена реализация. Так вот — именно в этом случае, таки да, после формулирования ТЗ всех уровней годится (но не является единственной!) разработка снизу вверх — просто потому, что уже неважно, в каком порядке разрабатывать D>Кошмар. Это из какой-то идеальной вселенной, где и заказчику ничего в голову не может взбрести по дороге, и исполнители все как один гений на гении и никогда не вляпываются в "гладко было на бумаге".
А ты думаешь, почему с этой моделью проблемы на практике? И тем не менее её кое-где до сих используют, а если что-то происходит за её пределами, то чисто неофициально.
D> Не, в какой-нибудь военке или космонавтике это может и единственно верный подход. Но не такой уж большой процент программистов работают на военку и космонавтику.
Как раз там такой подход не используется — никто не разрабатывает каждый раз новый самолёт с нуля. Могут идти в дело целые блоки от прежних, разве что перекрашенные Данные отрасли отличаются значительно большим документированием каждого этапа, строжайшей прописью всех особенностей ТЗ, сложными условиями тестирования и приёмки. Кстати, подход, который я описывал, в значительной мере основан на подобных высоких требованиях — он только их "заземляет" в доступной форме для "гражданской" разработки.
N>>>>Строго наоборот Небольшой тактический проигрыш на написание мока D>>>И незабывание поддержания его поведения согласованным с изменяющимся поведением системы. Впрочем, если у тебя "сверху вниз" и всё поведение заранее продумано и гвоздями прибито... N>>Неверное и некорректное допущение. D>Где именно? Ты ж только что сам выше разжевал про водопадную модель, что гвоздями прибито "безвозвратно".
Так я и говорю, что я её не применяю
D>>>При "снизу вверх", как я выше описал, я точно также строю ровно то, что надо, и не граммом больше. N>>Потому что ты уже прошёлся сверху вниз мысленно. D>Ага. Очень быстро прошёлся, практически без затрат времени. И избавил себя от затрат времени на моки всякие.
Ну по тому, что ты описал, у тебя очень плоская обстановка, там можно обойтись и без моков...
А в реальности нужно искать в памяти в объёме, влезающем в L1. Во-вторых, стыки с соседними функциональными блоками всё равно разрабатываются под некоторую функциональность этих блоков, отсюда возникают моки. Извини, я не могу себе представить крупную задачу, в которой можно настолько раздельно тестировать все слои и подсистемы...
