Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>>На другом проекте все еще хуже — данные плохо формализуются и написание тестов для автоматической проверки некоторых задач может потянуть на PhD. Поэтому проще сделать собственный отладчик и вручную проверять работу алгоритмов. Ну и ассерты помогают.
M>Звучит странно. Даже в таких непростых областях как классификация изображений , тесты очень неплохо используются. поделитесь задачей
В одном из срачей я уже приводил пример одной задачи — триангуляция 2Д объектов. Можно проверить, что внешний контур остался неизменным, а вот убедиться, что внутри не получилось каши — задачка не на 5 минут. Ее можно решить, но сложность ее гораздо выше, чем сам алгоритм триангуляции.
И я так и не добился в тот раз ответа на вопрос, должны ли мы Тест обкладывать тестами?
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, abibok, Вы писали:
A>На практике угадывать с тестами — примерно то же самое, что угадывать с оптимизацией. На этапе проектирования можно разработать и test spec (не test plan), но бросаться писать абстрактные тесты того, чего еще нет даже в черновом варианте я бы не стал.
Тогда я не понимаю что вы имеете в виду, говоря "разработчики пишут юнит-тесты вместе с написанием кода". Значит всё-таки не "вместе" а "после", уже имея возможность оценить на что писать а на что — нет?
SVZ>В одном из срачей я уже приводил пример одной задачи — триангуляция 2Д объектов. Можно проверить, что внешний контур остался неизменным, а вот убедиться, что внутри не получилось каши — задачка не на 5 минут. Ее можно решить, но сложность ее гораздо выше, чем сам алгоритм триангуляции.
Для юнит теста не стоит задача проверить верность алгоритма, достаточно выбрать несколько заранее определенных ключевых сценариев (в данном случае форм объектов, для которых выполнение алгоритма пойдет по разным веткам) и убедиться, что алгоритм возвращает в целом непротиворечивый результат. Так чтобы действительно серьезный баг или поломка в результате рефакторинга обрушили тест. Небольшие, особо хитрые баги все еще будут проходить незамеченными, и это совершенно нормально. Каждый раз, когда такой баг будет обнаруживаться вы будете добавлять к тесту новый сценарий, покрывающий данную категорию объектов.
SVZ>И я так и не добился в тот раз ответа на вопрос, должны ли мы Тест обкладывать тестами?
Тесты для тестов — совершенно нормальная практика, к которой в конце концов приходит каждый, кто управляет большим набором тестов для достаточно сложного продукта. Первое приближение тестов для тестов — это использование моков. Мы подменяем реальный продукт его моком, который ломается в заранее известных местах, и проверяем, что тесты способны это выловить и не дать ложных срабатываний.
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). Плюс перемножение матриц — не очень удачный пример. Как бы вы управляли тестами реализации сетевого протокола? Можно услышать немного личного опыта вместо теоретических рассуждений?
Здравствуйте, abibok, Вы писали:
A>Как отличить плохой тест от хорошего? Как узнать, не стал ли тест плохим при очередном изменении тестируемого кода? Как писать тесты без ошибок с первого захода?
Это тема кажется совсем другая.
A>Проверка контрактов включает в себя как позитивные, так и негативные тесты. Но говорим мы совсем не об этом. Все эти тесты применяются как к оригинальному продукту, так и к продукту с известными проблемами (что достигается путем моков или failure injection models). Плюс перемножение матриц — не очень удачный пример.
По моему великолепный пример, компактный, емкий , понятный. А вы так не уточнили , что подразумевали в изначальном посте под тестом теста.
A>Как бы вы управляли тестами реализации сетевого протокола? Можно услышать немного личного опыта вместо теоретических рассуждений?
Что вас конкретно интеревует , тема большая , много текста писать не хочется. Но вроде задача не рокет сайнс, никаких трудностей не вижу.
Здравствуйте, abibok, Вы писали:
A>Тесты для тестов — совершенно нормальная практика, к которой в конце концов приходит каждый, кто управляет большим набором тестов для достаточно сложного продукта. Первое приближение тестов для тестов — это использование моков. Мы подменяем реальный продукт его моком, который ломается в заранее известных местах, и проверяем, что тесты способны это выловить и не дать ложных срабатываний.
Интересно, а собственно прикладной код вы писать успеваете? По скольку часов в неделю?
Не, если у вас mission critical — то без вопросов. В любом другом случае — бессмысленный overkill.
Здравствуйте, abibok, Вы писали:
A>Тесты для тестов — совершенно нормальная практика, к которой в конце концов приходит каждый, кто управляет большим набором тестов для достаточно сложного продукта. Первое приближение тестов для тестов — это использование моков. Мы подменяем реальный продукт его моком, который ломается в заранее известных местах, и проверяем, что тесты способны это выловить и не дать ложных срабатываний.
Собственно, в тесте уже прописано, на каких данных он должен падать, а на каких нет. Тест и тестируемый код тут в связке, и чтобы не заметить баг, надо внести взаимно-аннигилирующие правки и в код, и в тест, вероятность чего мизерна. Так что тесты для тестов — нафиг не нужны. А к использующим их у меня напрашивается естественный вопрос: а тесты для тестов для тестов и тесты для тестов для тестов для тестов у вас есть? И если нет, то почему.
Здравствуйте, dimgel, Вы писали:
A>>Тесты для тестов — совершенно нормальная практика, к которой в конце концов приходит каждый, кто управляет большим набором тестов для достаточно сложного продукта. Первое приближение тестов для тестов — это использование моков. Мы подменяем реальный продукт его моком, который ломается в заранее известных местах, и проверяем, что тесты способны это выловить и не дать ложных срабатываний.
D>Собственно, в тесте уже прописано, на каких данных он должен падать, а на каких нет. Тест и тестируемый код тут в связке, и чтобы не заметить баг, надо внести взаимно-аннигилирующие правки и в код, и в тест, вероятность чего мизерна. Так что тесты для тестов — нафиг не нужны.
В процессе написания и при экспериментировании с ответами — да. А вот представь себе, что тест уже написан, и он использует какой-нибудь специфический assertIsTrueWithContext(), и вот очередная переделка незаметно привела к тому, что этот вызов всегда успешен, что бы ни происходило. Причём эта переделка происходит в коде, отстоящем от данного на несколько десятков каталогов. Вопрос — а как ты собственно это заметишь?
Поэтому первый тип "тестов на тесты" это тесты собственно тестовой инфраструктуры, если она сложнее того, что один человек может охватить взглядом за раз. Работоспособность тестовой инфраструктуры тоже должна быть подтверждена, и проверяться — на каждом запуске.
Второе — наша специфика, возможно, пригодна не всем, но у нас есть категория инверсных тестов. Например, мы знаем, что компонент 1, получив сигнал A, выдаёт B, а компонент 2 на его основе генерирует C. Не подав компоненту 1 на вход A, мы не можем получить на выходе C. Инверсный тест проверяет, что нарушение входных условий приводит к отрицательному общему выводу (С не получен). Это таки тестирование теста, а точнее, условий, лежащих в его основе. Для каждого теста продумывается набор таких точек, нарушение которых приводит к нарушению результата теста, и они записываются в список на проверку (например, в Makefile).
Пример коллеги abibok с моком — это такой же вариант, но с развитием событий не во времени, а в специфике взаимодействия компонент, и потому пригоден для класса задач, в которых временной фактор не играет принципиальной роли.
D> А к использующим их у меня напрашивается естественный вопрос: а тесты для тестов для тестов и тесты для тестов для тестов для тестов у вас есть? И если нет, то почему.
Потому что данного уровня в сочетании с ревью кода и живым QA пока что было достаточно.
Возможно, при выходе за какие-то безумные пределы размера и сложности потребовалось бы ещё что-то, не знаю, не сталкивался.
Здравствуйте, vb-develop, Вы писали:
VD>Если есть успешный опыт внедрения процесса написания тестов в проекте, тоже было бы интересно послушать.
Один из моих текущих проектов — VoIP свич — изначально был порождён без любых явных тестов на уровне кода и просуществовал в таком виде в течение приблизительно 5 лет, из которых 2 я был единственным разработчиком, а ещё один до того — вспомогательным. Тестирование проводилось отработкой конкретных сценариев вживую, с использованием соответствующей аппаратуры ("железные" телефоны и их аналоги).
Однако начиная с определённого уровня сложности стало слишком много наведённых эффектов, когда работы в одном месте стали ломать другие места. Объём кода тогда уже был очень существенным. Когда пригласили ещё одного человека и он начал шустро ломать работающее, я понял, что так дальше нельзя и лучше явно затормозить разработку, чем ломать релизы
Автоматизация тестирования началось с построения теста, который можно было бы по современным классификациям назвать чем-то средним между функциональным и интеграционным: создавалась среда, имитирующая рабочую, и участники — эмуляторы удалённых телефонов — прогоняли один звонок. Это было ничтожно мало, но начало было положено Я разметил пространство возможных тестов, пронумеровав его, и начал дальше покрывать разные случаи, по примерно следующему принципу:
1. Если на какое-то место выписан баг, то не закрывать тикет без нового теста, который бы этот баг опознал и стал удовлетворённым по результату фикса.
2. Все новые разработки покрываются тестами изначально (без этого старались не признавать разработку завершённой).
3. Если есть свободное время, то рисуется следующий тест в порядке убывания известной мне проблемности подсистемы/слоя/etc.
Конкретный вид теста рассматривался по обстановке, но предпочтение давалось максимально высокоуровневому в каждом случае, то есть тест на эмуляцию рабочей обстановки важнее теста для одного слоя, а тот — важнее, чем юнит-тест.
Потребовалось некоторое количество внушений коллегам, чтобы они проверяли сами результаты своего кодинга перед коммитом; к счастью, не было откровенно невменяемых участников, и двух-трёх случаев хватило на всех.
Потом я ушёл оттуда года на полтора, а когда вернулся — с новым руководителем всего подразделения разработки пришла и новая практика, включая переход на git вместо зоопарка CVS/SVN, использование ревью (gerrit) с автоконтролем существующих уже тестов (через Jenkins). Сейчас картина такова, что тесты покрывают около половины всех развилок и около 3/4 всего кода; и теперь меня уже агитируют делать как следует и рассказывают, как надо, а не наоборот Хотя в результате кросс-опыления идеями между работами туда пришла, например, идея инверсных тестов (и парочка таки сработала, когда надо).
Самым сложным в данном проекте обычно оказывается найти метод отвязаться от реальной обстановки и создать её адекватную эмуляцию для данной подзадачи. Очень много внешних связей, которые надо заглушить (ставятся заглушки всех мастей, от тупого запрета в конфиге до моков со сложным поведением).
Здравствуйте, netch80, Вы писали:
N>Второе — наша специфика, возможно, пригодна не всем, но у нас есть категория инверсных тестов. Например, мы знаем, что компонент 1, получив сигнал A, выдаёт B, а компонент 2 на его основе генерирует C. Не подав компоненту 1 на вход A, мы не можем получить на выходе C. Инверсный тест проверяет, что нарушение входных условий приводит к отрицательному общему выводу (С не получен). Это таки тестирование теста, а точнее, условий, лежащих в его основе.
Не понял, почему это тестирование теста. Насколько я понял, это точно такое же тестирвоание прикладного кода. Скажем, по входным данным (A,B,C) может быть сгенерирована пара тестов: A -> B -> C, !A -> !B -> !C. Оба теста — прикладные. Если же речь идёт про необходимость тестировать код, генерирующий эту самую пару тестов по входным наборам данных, то ИМХО это таки-оверкилл. Потому что вероятность появления описанной тобой ситуации:
>А вот представь себе, что тест уже написан, и он использует какой-нибудь специфический assertIsTrueWithContext(), и вот очередная переделка незаметно привела к тому, что этот вызов всегда успешен, что бы ни происходило
причём такой, чтобы в итоге все тесты успешно выполнялись, а не падали, мизерна. Хотя... если увлекаться тестированием сверху вниз, т.е. моками всякими, и вообще перегружать тестовый фреймворк винтиками — всякое возможно. Я всегда тестируюсь снизу вверх, у меня даже база настоящая, без моков (а точнее, несколько автоматически создаваемых баз по количеству параллельно выполняющихся тестов). Поэтому тестовый фреймворк предельно компактный, и ломаться там особо-то и нечему.
Здравствуйте, 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> Хотя... если увлекаться тестированием сверху вниз, т.е. моками всякими, и вообще перегружать тестовый фреймворк винтиками — всякое возможно. Я всегда тестируюсь снизу вверх, у меня даже база настоящая, без моков (а точнее, несколько автоматически создаваемых баз по количеству параллельно выполняющихся тестов). Поэтому тестовый фреймворк предельно компактный, и ломаться там особо-то и нечему.
Если бы ещё было понятно, что такое "сверху вниз" в данном контексте...
