Для проведения теста Тьюринга нужно грамотно выбрать группу экспертов. Иначе это будет профанация.
Как это сделать? А очень просто, с помощью обратного теста Тьюринга. Т.е. если группа экспертов не может отличить человека от компьютера, то мы её выгоняем.
А теперь серьёзно. Существует практический аспект обратного теста Тьюринга.
Это методика обратного тестирования. Я её использую при разработки ответственного софта.
Суть её в следующем. Мы пишем некоторый софтварный компонент.
Далее мы пишем тесты для него. Прогоняем.
Большинство программистов на этой стадии останавливаются. Но останавливаться не надо.
Следующий шаг -- обратное тестирование. Мы берем исходный код и целенапрвленно вводим в него дефекты. И запускаем тесты.
Если тесты не улавливают наличие дефектов, то тест-систему корректируем.
Здравствуйте, Шахтер, Вы писали:
Ш>Это методика обратного тестирования. Я её использую при разработки ответственного софта. Ш>Если тесты не улавливают наличие дефектов, то тест-систему корректируем.
Отлично! Так и надо. Только дефекты в коде уже есть, их не надо вносить, их надо искать вручную.
Здравствуйте, Шахтер, Вы писали:
Ш>Для проведения теста Тьюринга нужно грамотно выбрать группу экспертов. Иначе это будет профанация. Ш>Как это сделать? А очень просто, с помощью обратного теста Тьюринга. Т.е. если группа экспертов не может отличить человека от компьютера, то мы её выгоняем.
Вообще-то обратный тест — это когда эксперты не могут отличить человека от бота
Ш>А теперь серьёзно. Существует практический аспект обратного теста Тьюринга. ... Ш>Следующий шаг -- обратное тестирование. Мы берем исходный код и целенапрвленно вводим в него дефекты. И запускаем тесты. Ш>Если тесты не улавливают наличие дефектов, то тест-систему корректируем.
Эмм, это к Тьюрингу не имеет никакого отношения, обычная проверка на false positives. Имхо, такие вещи не должны использоваться в сколько-нибудь серьёзных проектах. Доводы следующие:
1. Введение дефектов не автоматизируется, т.е. регулярно выполняться не будет. Получаем реальный шанс false positive в тестах на false positive. Need to go deeper?
2. (*если мы говорим о юнит-тестах) Тесты не должны тестировать внутренности реализации, только отслеживать соответствие "тестируемое поведение <-> спецификация API". Любая попытка "заглянуть глубже" неизменно приводит к тому, что расходы на тестирование перекрывают выигрыш на порядок.
То же самое, но чуть другими словами: если баг не затрагивает тестируемое поведение, то тест не может/не должен обнаруживать косяки. Например, если при тестировании API калькулятора у нас идёт утечка памяти, запись мусора в базу или пропадают кнопки в UI model, но все суммы сходятся, то тест пройден, как бы парадоксально это не звучало.
За ловлю вышеперечисленных косяков должны отвечать или специализированные тесты (интеграционные, дифф-тесты, ui-тестирование), или, ещё лучше, ассерты. В пользу ассертов говорит то, что они работают всегда и позволяют отловить косяки, которые в тепличных условиях юнит-теста фиг воспроизведёшь.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Шахтер, Вы писали:
Ш>>Если тесты не улавливают наличие дефектов, то тест-систему корректируем.
J>Звучит как TDD наоборот J>В смысле, в TDD тесты сначала должны валиться, а в конце все хорошо, а тебя наоборот.
Тесты валится не должны. Они валится могут, если ты сделал ошибку в коде.
Вопрос в другом -- в достаточности множества тестов.
Здравствуйте, Шахтер, Вы писали:
Ш>>>Если тесты не улавливают наличие дефектов, то тест-систему корректируем.
J>>Звучит как TDD наоборот J>>В смысле, в TDD тесты сначала должны валиться, а в конце все хорошо, а тебя наоборот.
Ш>Тесты валится не должны. Они валится могут, если ты сделал ошибку в коде.
Так в том и дело. Ты стартуешь с (предположительно) правильно написанного кода и только потом пишешь к нему тесты.
А в TDD стартуют с неправильного (или вообще отсутствующего) кода. Т.е. правильного кода еще нет, а тесты уже есть, и они все не срабатывают. И твоя цель — сделать тесты срабатывающими.
И ты думаешь о достаточности тестов до того, как начнешь писать код (т.е. фактически формулируешь требования к коду и излагаешь их на языке тестов).
И тесты становятся своего рода документацией к (ненаписанному еще) коду, показывая, что должно срабатывать, а что не должно.
Ш>Вопрос в другом -- в достаточности множества тестов.
Да я понял Просто есть сходство.
Здравствуйте, Sinix, Вы писали:
S>Вообще-то обратный тест — это когда эксперты не могут отличить человека от бота
Не, обратный — это когда комп может отличить человека от бота
Здравствуйте, jazzer, Вы писали:
J>Так в том и дело. Ты стартуешь с (предположительно) правильно написанного кода и только потом пишешь к нему тесты. J>А в TDD стартуют с неправильного (или вообще отсутствующего) кода. Т.е. правильного кода еще нет, а тесты уже есть, и они все не срабатывают. И твоя цель — сделать тесты срабатывающими. J>И ты думаешь о достаточности тестов до того, как начнешь писать код (т.е. фактически формулируешь требования к коду и излагаешь их на языке тестов). J>И тесты становятся своего рода документацией к (ненаписанному еще) коду, показывая, что должно срабатывать, а что не должно.
Я считаю TDD халтурой. Потому что не имея кода нельзя написать разумную систему тестов. В лучшем случае TDD вскроет ошибки в алгоритмах. Для того, что бы вскрыть ошибки в реализации, надо проанализировать код
и писать тесты отталкиваясь от кода. Кстати, это ещё одна причина, почему идея Тьюринга (тест Тьюринга) принципиально порочна. Нельзя делать вывод о разумности, не имея хотя бы некоторых представлений о реализации.
Здравствуйте, Шахтер, Вы писали:
Ш>Следующий шаг -- обратное тестирование. Мы берем исходный код и целенапрвленно вводим в него дефекты. И запускаем тесты.
это очень древняя методика. она использовалась еще когда ассемблера не было.
в программу умышленно вносится определенное число ошибок. пускай для определенности сто. если в результате тестирования выявлено только 50, то это позволяет нам оценить качество тестирования и кол-во скрытых ошибок в релизе.
так что новое это хорошо забытое старое.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Шахтер, Вы писали:
Ш>Здравствуйте, jazzer, Вы писали:
J>>Так в том и дело. Ты стартуешь с (предположительно) правильно написанного кода и только потом пишешь к нему тесты. J>>А в TDD стартуют с неправильного (или вообще отсутствующего) кода. Т.е. правильного кода еще нет, а тесты уже есть, и они все не срабатывают. И твоя цель — сделать тесты срабатывающими. J>>И ты думаешь о достаточности тестов до того, как начнешь писать код (т.е. фактически формулируешь требования к коду и излагаешь их на языке тестов). J>>И тесты становятся своего рода документацией к (ненаписанному еще) коду, показывая, что должно срабатывать, а что не должно.
Ш>Я считаю TDD халтурой. Потому что не имея кода нельзя написать разумную систему тестов. В лучшем случае TDD вскроет ошибки в алгоритмах.
Не совсем так. Ты в любом случае ведь пишешь код, отталкиваясь от требований к нему. Начиная от функциональных требований (что должен делать и когда какие результаты выдавать) и заканчивая нефункциональными (время работы и т.п.). TDD требует выразить все эти требования в виде тестов к еще ненаписанному коду.
Это позволяет (по моему собственному опыту) сконцентрироваться именно на требованиях и на разных темных углах и узких местах спецификации и проработать вопрос гораздо глубже, чем при написании тестов после кода.
Тут очень важно, что кода еще нет — реализация не застит глаза, и ты пишешь тесты, отталкиваясь о того, что код должен делать, а не от того, что он (случайно) делает в данной реализации.
Ш>Для того, что бы вскрыть ошибки в реализации, надо проанализировать код и писать тесты отталкиваясь от кода.
В качестве второго этапа — можно, но это не отменяет рулезов TDD.
Ну и потом это тоже ведь хождение по граблям.
Ну будет у тебя в реализации какая-то особая точка, скажем, ты делишь на 3-x, и поэтому надо особо обрабатывать случай x=3. Ну, допустим, ты это заметил, даже тест написал. А потом пересчитал свою матмодель и поменял реализацию на 5-x — все твои существующие тесты замечательно это схавают, если в них случайно не будет проверки случая x=5 (а с чего бы). И что, выкинуть 3, добавить 5? или добавить тестирование всего натурального ряда, и заодно числа пи — мало ли как еще изменится реализация?
Ш>Кстати, это ещё одна причина, почему идея Тьюринга (тест Тьюринга) принципиально порочна. Нельзя делать вывод о разумности, не имея хотя бы некоторых представлений о реализации.
Предполагается, что людям для определения разумности собеседника достаточно иметь представление о разумности вообще.
А вот знать устройство мозга и биоэлектрохимию синапсов для этого совсем необязательно.
Ш>Следующий шаг -- обратное тестирование. Мы берем исходный код и целенапрвленно вводим в него дефекты. И запускаем тесты. Ш>Если тесты не улавливают наличие дефектов, то тест-систему корректируем.
Я читал про такое тестирование ещё в древней университетской методичке. К сожалению, не могу вспомнить имя лектора и найти методичку. Почему-то все любители Unit тестирования очень обижаются, когда я предлагаю им проверить качество их тестирования, например, элементарно заменив >= на > в некоторых местах.
Здравствуйте, jazzer, Вы писали:
Ш>>Если тесты не улавливают наличие дефектов, то тест-систему корректируем.
J>Звучит как TDD наоборот J>В смысле, в TDD тесты сначала должны валиться, а в конце все хорошо, а тебя наоборот.
Это не тдд наоборот, это контроль качества тестов. С тдд очень легко написать код, в котором тесты будут проверять только моки и тестовые данные.
Здравствуйте, Sinix, Вы писали:
S>Эмм, это к Тьюрингу не имеет никакого отношения, обычная проверка на false positives. Имхо, такие вещи не должны использоваться в сколько-нибудь серьёзных проектах. Доводы следующие:
S>1. Введение дефектов не автоматизируется, т.е. регулярно выполняться не будет. Получаем реальный шанс false positive в тестах на false positive. Need to go deeper?
Да, задача не автоматизируется. Но это не значит, что нужно забивать на неё. Написание логики тоже не автоматизируется. Зато с помощью предложеного способа можно найти куски проекта, кторые как бы покрыты тестами, а на самом деле тесты или работают при нерабочем приложении, или отваливаются при рабочем приложении.
То есть, приложение не работает, но проходит тесты, или приложение работает но тесты не проходит. Если такие проблемы не свести к минимуму, то совершенно не ясно, для чего нужны собственно тесты.
Отсюда вопрос — покажи как свести к минимум эти проблемы, не пользуясь предложеным способом.
Здравствуйте, Ikemefula, Вы писали:
S>>1. Введение дефектов не автоматизируется, т.е. регулярно выполняться не будет. Получаем реальный шанс false positive в тестах на false positive. Need to go deeper? I>Да, задача не автоматизируется. Но это не значит, что нужно забивать на неё. Написание логики тоже не автоматизируется. Зато с помощью предложеного способа можно найти куски проекта, кторые как бы покрыты тестами, а на самом деле тесты или работают при нерабочем приложении, или отваливаются при рабочем приложении.
На мой взгляд, это шаманство в самом плохом смысле слова. Ну, как гадать на погоду по мокрому пальцу, когда рядом стоит метеостанция.
Уже есть стабильные, автоматизируемые, повторяемые методики тестирования. Ты сам наверно знаешь, просто перечислю:
* Для анализа покрытия тестами есть само покрытие тестами плюс поиск непокрытых вариантов через code flow analysis (см chess/pex).
* Для случайных ошибок-опечаток — компилятор, статический анализ, code contracts, валидация аргументов и ассерты.
* Для поиска неочевидных ошибок и нарушений любых инвариантов — всё те же ассерты и инструментирование через AOP (postsharp или инварианты в CodeContracts). Этот пункт великолепно уживается с отладочными сборками, интеграционными и ui-тестами. И, в отличие от юнит-тестов, как раз позволяют тестировать детали реализации.
* Для софта с экстремальными требованиями по надёжности есть полная статическая верификация и генерация кода по верифицированной матмодели + дифф-тесты по эталону.
Что может дать нового методика "ломаем код, запускаем" (aka мета-тестирование) с учётом всего вышеперечисленного?
Ну ок, допустим, тесты упали. Значит ли это что всё хорошо и тесты корректны? Нифига, нет никаких гарантий, что тесты не пропустят любую другую ошибку.
Допустим, тесты не упали. Это тоже не показывает ничего, кроме того что код надо смотреть. Возможно, ошибку внесли в код, который отключен на текущей итерации. Возможно, тесты не покрывают какой-то частный набор сценариев (который скорее всего нигде не используется). Возможно, обработка ошибок предусмотрена уровнем выше и оговорена в тестах. Возможно, ошибка ловится ассертом, который был отключен на время тестирования.
Ок, покрываем этот сценарий тестами. См предыдущий пункт — где гарантии, что покрыты все варианты, или что непокрытый код не появится потом?
В любом из вариантов мы узнаем только одно — надо разбираться в коде, чтобы определить где косяк: в тестах, в коде или в техзадании. Сорри, но то же самое известно и так, без лишних приседаний. По затратам: code review на предмет места для поломки + запуск тестов + анализ результатов + добавление тестов + тестирование добавленных тестов — мы обменяли иллюзию "у нас всё хорошо" где-то на пару-тройку незакрытых тикетов.
О чём и было сказано выше: любая попытка при помощи юнит-тестов "заглянуть глубже" публичного API неизменно приводит к тому, что расходы на тестирование перекрывают выигрыш на порядок.
I>То есть, приложение не работает, но проходит тесты, или приложение работает но тесты не проходит. Если такие проблемы не свести к минимуму, то совершенно не ясно, для чего нужны собственно тесты. I>Отсюда вопрос — покажи как свести к минимум эти проблемы, не пользуясь предложеным способом.
Элементарно — ассерты + использование кода
Давай ещё раз. Ни одно из средств тестирования само по себе не даёт гарантии, что в коде нет ошибок. В комплексе они также не дают 100% уверенности, но обеспечивают достаточный уровень надёжности софта.
Посмотри на блог PVS-Studio: что ни софт — так тонны глупых ошибок, опечаток, копипасты и тд и тп. Тем не менее, на практике ни одна из этих ошибок не была обнаружена раньше (кэп, ага). Очевидно, большинству клиентов от наличия/отсутствия этих ошибок ни холодно, ни жарко.
Мне понравился ответ на типовой вопрос в комментариях к одной из статей:
evocatus
Глупый вопрос: как вообще это всё работает? Вы уже немало статей написали с явными ошибками. Не синтаксическими, а логическими. Если их ещё не исправили, значит они не заметны и программа вроде как работает. Почему? Ведь надёжность сложной системы, составленной из блоков, меньше, чем сумма надёжностей этих блоков?
tzlom
Едет ли машина у которой не горят фары?
Так вот, тестирование через поломку кода нифига не поможет найти нерабочие фары. Максимум, поймать ДПС-ника, пропустившего машину, сдающую задним ходом с негорящим белым. Ну и нафига оно надо производителю? Особенно если учесть, что подобная ошибка скорее всего будет обнаружена пользователем раньше и починена при первом обращении в поддержку.
Здравствуйте, Sinix, Вы писали:
S>На мой взгляд, это шаманство в самом плохом смысле слова. Ну, как гадать на погоду по мокрому пальцу, когда рядом стоит метеостанция.
S>Уже есть стабильные, автоматизируемые, повторяемые методики тестирования. Ты сам наверно знаешь, просто перечислю:
Я просил не методики тестирования, а проверку тестов.
Как выяснить, что твои тесты действительно полезны ?
Здравствуйте, Шахтер, Вы писали:
J>>Так в том и дело. Ты стартуешь с (предположительно) правильно написанного кода и только потом пишешь к нему тесты. J>>А в TDD стартуют с неправильного (или вообще отсутствующего) кода. Т.е. правильного кода еще нет, а тесты уже есть, и они все не срабатывают. И твоя цель — сделать тесты срабатывающими. J>>И ты думаешь о достаточности тестов до того, как начнешь писать код (т.е. фактически формулируешь требования к коду и излагаешь их на языке тестов). J>>И тесты становятся своего рода документацией к (ненаписанному еще) коду, показывая, что должно срабатывать, а что не должно.
Ш>Я считаю TDD халтурой. Потому что не имея кода нельзя написать разумную систему тестов.
ТДД это не написание системы тестов. ТДД оно про проектирование. Знать код не нужно, но вот представлять, как решается задача очень даже нужно. Скажем, нужно хотя бы представлять более-менее детально вычислительную модель.
>В лучшем случае TDD вскроет ошибки в алгоритмах. Для того, что бы вскрыть ошибки в реализации, надо проанализировать код Ш>и писать тесты отталкиваясь от кода. Кстати, это ещё одна причина, почему идея Тьюринга (тест Тьюринга) принципиально порочна. Нельзя делать вывод о разумности, не имея хотя бы некоторых представлений о реализации.
ТДД это пример как хорошая методика из за плохого названия трактуется как попало.
Здравствуйте, De-Bill, Вы писали:
Ш>>Следующий шаг -- обратное тестирование. Мы берем исходный код и целенапрвленно вводим в него дефекты. И запускаем тесты. Ш>>Если тесты не улавливают наличие дефектов, то тест-систему корректируем.
DB>Я читал про такое тестирование ещё в древней университетской методичке. К сожалению, не могу вспомнить имя лектора и найти методичку. Почему-то все любители Unit тестирования очень обижаются, когда я предлагаю им проверить качество их тестирования, например, элементарно заменив >= на > в некоторых местах.
Я подозреваю, что мы просто решаем довольно разные по характеру задачи. Может TDD где-то и полезно, но я как-то не проникся.
Ш>>Кстати, это ещё одна причина, почему идея Тьюринга (тест Тьюринга) принципиально порочна. Нельзя делать вывод о разумности, не имея хотя бы некоторых представлений о реализации.
J>Предполагается, что людям для определения разумности собеседника достаточно иметь представление о разумности вообще. J>А вот знать устройство мозга и биоэлектрохимию синапсов для этого совсем необязательно.
Это слишком низкий уровень. Нужен уровень логики.
Давай я приведу пример, чтобы моя мысль была более ясной. Представь, что мы проверяем уровень знаний с помощью системы тестов, типа ЕГЕ.
Вот машина взяла и ответила правильно на 100% вопросов, значит ли это, что она знает предмет? Вовсе нет, представь себе, что эта машина -- всего-навсего база данных готовых ответов.
Интелект способен рождать новую информацию. Но при тестировании нужно быть уверенным, что система действительно родила что-то новое, а не просто вспомнила, как надо отвечать в конкретном случае.
Не случайно, на экзаменах задают задачи и дополнительные вопросы на понимание. Чтобы отсеять безмозглых зубрил.
Здравствуйте, Ikemefula, Вы писали:
I>Я просил не методики тестирования, а проверку тестов.
А кто сказал, что тесты надо целенаправленно проверять? Какой риск мы этим устраняем?
Пропустить ошибку из-за некорректного теста? Так ошибку можно пропустить по сотне других причин, для лечения этих рисков есть тонна способов дешевле метатестирования — от статистики билд-сервера и до ретро-тестов, когда новый тест автоматом прогоняется на нескольких предыдущих версиях исходников. Вот тут как раз даже ломать ничего не надо — уже известно и когда поломалось, и когда починилось.
Остаться с неполным набором тестов? Так этот риск не устраняется в принципе, только сводится к приемлемому уровню. Опять-таки более дешёвыми способами.
Остаться с старой версией теста при новых исходниках? Так рандомные поломки кода никак этот риск не уменьшат.
В общем, нужна хоть одна причина по которой рутинное ручное тестирование может оказаться лучше и дешевле автоматизированного.
I>Как выяснить, что твои тесты действительно полезны ?
Если не скатываться к чисто формальным показателям типа покрытия, то только проверкой соотношения общих затрат на поддержку с тестами и без них. Других работающих способов я что-то не припомню.
Здравствуйте, Sinix, Вы писали:
I>>Я просил не методики тестирования, а проверку тестов. S>А кто сказал, что тесты надо целенаправленно проверять? Какой риск мы этим устраняем?
Как обычно — сроки, бюджет.
Если ты не можешь обосновать, какую пользу приносят тесты, то у тебя просто тесты ради тестов.
S>Пропустить ошибку из-за некорректного теста? Так ошибку можно пропустить по сотне других причин, для лечения этих рисков есть тонна способов дешевле метатестирования — от статистики билд-сервера и до ретро-тестов, когда новый тест автоматом прогоняется на нескольких предыдущих версиях исходников. Вот тут как раз даже ломать ничего не надо — уже известно и когда поломалось, и когда починилось.
Стало быть у тебя тесты ради тестов.
S>В общем, нужна хоть одна причина по которой рутинное ручное тестирование может оказаться лучше и дешевле автоматизированного.
Алё — от тебя требуется показать, как фактически доказать тот факт, что тесты приносят пользу и решают проблемы.
Это возможно с любым инструментом. Более того, если невоможно верифицировать эту самую пользу, инструмент ничем не отличается от баззворда.
I>>Как выяснить, что твои тесты действительно полезны ? S>Если не скатываться к чисто формальным показателям типа покрытия, то только проверкой соотношения общих затрат на поддержку с тестами и без них. Других работающих способов я что-то не припомню.
Поздравляю — твоя теория неверифицирума и нефальсифициуема.
Здравствуйте, Шахтер, Вы писали:
Ш>и писать тесты отталкиваясь от кода. Кстати, это ещё одна причина, почему идея Тьюринга (тест Тьюринга) принципиально порочна. Нельзя делать вывод о разумности, не имея хотя бы некоторых представлений о реализации.
Не о реализации, а о спецификации. Нужно понимать, что тесты дискретны, а спецификация непрерывна. Отсюда ясно, что проверять надо более жОстко.
Скажем, ассерт может гарантировать что функция всегда возвращает ненулевой результат, а вот десяток, сотня или хоть даже миллион тестов не может этого гарантировать.
S>>А кто сказал, что тесты надо целенаправленно проверять? Какой риск мы этим устраняем? I>Как обычно — сроки, бюджет. Сорри, но на работе ты тоже на вопрос о рисках, которые ты пытаешься решить отвечаешь "сроки-бюджет"???
Давай ещё раз. Можешь обосновать, почему при поставленном процессе тестирования нужно изобретать методику мета-тестирования, которая может производиться только вручную?
I>Стало быть у тебя тесты ради тестов.
Ты ж понимаешь, что вместо обсуждения переходишь к навешиванию ярлыков? У меня в проекте может вообще не быть тестов, может быть весь спектр, может использоваться что-то одно. Какое отношение это имеет к обсуждаемому вопросу?
S>>В общем, нужна хоть одна причина по которой рутинное ручное тестирование может оказаться лучше и дешевле автоматизированного. I>Алё — от тебя требуется показать, как фактически доказать тот факт, что тесты приносят пользу и решают проблемы.
Что-то я логики не уловил. Пока у нас диалог такой:
— Глупо складывать кучу чисел вручную, если рядом есть калькулятор.
— Обоснуй мне пользу от складывания чисел, тогда я тебе отвечу.
???
Фу-фу-фу так делать. Оставайся в рамках темы плиз, или если перескакиваешь на что-то, объясняй почему.
I>>>Как выяснить, что твои тесты действительно полезны ? S>>Если не скатываться к чисто формальным показателям типа покрытия, то только проверкой соотношения общих затрат на поддержку с тестами и без них. Других работающих способов я что-то не припомню.
I>Поздравляю — твоя теория неверифицирума и нефальсифициуема.
И снова навешиваешь ярлыки Проверяется элементарно, как и любая другая карго-методика: берём статистику по трекеру/билд-серверу, определяем ключевые показатели и сравниваем результаты до введения методики и после. Или есть ещё какая-то магия, которая позволяет оценить потенциальный выигрыш без мониторинга результатов?
Здравствуйте, Sinix, Вы писали:
S>>>А кто сказал, что тесты надо целенаправленно проверять? Какой риск мы этим устраняем? I>>Как обычно — сроки, бюджет. S> Сорри, но на работе ты тоже на вопрос о рисках, которые ты пытаешься решить отвечаешь "сроки-бюджет"???
А ты тоже по работе по три раза увиливаешь от ответа ?
S>Давай ещё раз. Можешь обосновать, почему при поставленном процессе тестирования нужно изобретать методику мета-тестирования, которая может производиться только вручную?
Потому что эффективность любого инструмента это не строчка из библии. Качество любой работы можно и нужно проверять.
Есть инструмент — есть ответ на вопросы "какую проблему он решает" и "как проверить, что таки решает"
I>>Стало быть у тебя тесты ради тестов. S>Ты ж понимаешь, что вместо обсуждения переходишь к навешиванию ярлыков? У меня в проекте может вообще не быть тестов, может быть весь спектр, может использоваться что-то одно. Какое отношение это имеет к обсуждаемому вопросу?
Ты не можешь внятно рассказать, как определять качество такой работы, как написание тестов, начинаешь кидаться баззвордами и тд. Вот я тебе и подыгрываю.
I>>Алё — от тебя требуется показать, как фактически доказать тот факт, что тесты приносят пользу и решают проблемы. S>Что-то я логики не уловил. Пока у нас диалог такой:
S>- Глупо складывать кучу чисел вручную, если рядом есть калькулятор. S>- Обоснуй мне пользу от складывания чисел, тогда я тебе отвечу. S>???
Нет, не такой. У ТС внятный результат: "Если тесты не улавливают наличие дефектов, то тест-систему корректируем."
Отсюда ясно, что речь про качество тестов.
В переводе на твой язык аналогий — "корректность работы калькулятора нужно доказать". Для калькулятора, кстати говоря, есть методика проверки, если ты не в курсе. Странно, да ?
I>>Поздравляю — твоя теория неверифицирума и нефальсифициуема. S>И снова навешиваешь ярлыки Проверяется элементарно, как и любая другая карго-методика: берём статистику по трекеру/билд-серверу, определяем ключевые показатели и сравниваем результаты до введения методики и после. Или есть ещё какая-то магия, которая позволяет оценить потенциальный выигрыш без мониторинга результатов?
Как ты сможешь по билд-системе и трекеру отделить эффект тестов от эффета любого другого фактора, который возник одновременно с введением тестов ?
Может просто команда обозлилась и пишет тесты для галочки, а основное время проводит в курилке и обдумывает(== проектирует), как бы решить проблему наименьшим количеством строчек кода. Или так — команда работает по принципу "лишь бы не поломать", а "все тяжелые" фичи зарезаются еще на стадии обсуждения "это сложно, мы не сможем покрыть все тестами, времени надо полгода"
Вот на этих примерх, взяты из жизни, кстати говоря, твой подход верификации покажет однозначный профит тестов.
То есть, более общая формулировка — на одном проекте ввели мега-процесс и получили срыв сроков, перерасход бюджетов, провальное качество и проект закрылся/заморозился/перешел на другой процесс. На другом сделали тоже самое и получили профит (сроки,бюджеты, качество). Опаньки !
Итого — одна и та же методология может давать прямо противоположные результаты. Примеров тому тысячи. Отсюда ясно, что вопрос открытый — на какие показатели ориентироваться когда вводишь скажем тесты и тд ?
Ну что, есть ответ или дальше будешь кидаться баззвордами ?
Здравствуйте, Ikemefula, Вы писали:
S>>>>А кто сказал, что тесты надо целенаправленно проверять? Какой риск мы этим устраняем? I>>>Как обычно — сроки, бюджет. I>А ты тоже по работе по три раза увиливаешь от ответа ?
Да вроде нигде не увиливал Тыкни носом, плиз.
S>>Давай ещё раз. Можешь обосновать, почему при поставленном процессе тестирования нужно изобретать методику мета-тестирования, которая может производиться только вручную? I>Потому что эффективность любого инструмента это не строчка из библии. Качество любой работы можно и нужно проверять.
Угу. Но только если затраты на проверку качества хоть как-то сопоставимы с выигрышом. Для варианта топикстартера это не так, т.к.
* методика не автоматизируется и не даёт повторяемых результатов
* она не проверяет то, что входит в ответственность юнит-тестов
* чтобы получить хоть какой-то эффект, затраты на ручное тестирование придётся как минимум сравнять с затратами на само тестирование.
* есть тонна методик, которые не страдают от перечисленных выше недостатков.
Давай ещё раз: почему при поставленном процессе тестирования нужно изобретать методику мета-тестирования, которая может производиться только вручную?
I>Есть инструмент — есть ответ на вопросы "какую проблему он решает" и "как проверить, что таки решает"
Угу, осталось ответить на вопрос "почему мы используем молоток для забивания шурупов?"
I>>>Стало быть у тебя тесты ради тестов.
... I>Ты не можешь внятно рассказать, как определять качество такой работы, как написание тестов, начинаешь кидаться баззвордами и тд. Вот я тебе и подыгрываю.
[Кэп]
Потому что качество — характеристика относительная. Чтобы определить лучше-хуже, надо смотреть на изменение ключевых показателей, а не на формальные цифры. Ну а дальше начинается специфичные для каждого проекта вещи, которую в абстрактном споре обсуждать бесполезно.
[/Кэп]
I>Нет, не такой. У ТС внятный результат: "Если тесты не улавливают наличие дефектов, то тест-систему корректируем." I>Отсюда ясно, что речь про качество тестов.
С чего бы это? Ты меряешь какую-то левую фигню, которая очень слабо совпадает с зоной ответственности юнит-тестов (если мы про них говорим). Юнит-тесты не могут и не должны определять произвольную поломку в коде, это задача ассертов/стресс-тестирования и прочих методик. Юнит-тесты отвечают за проверку совпадения спецификации и тестируемого поведения. Вероятность того, что рандомная поломка выявит именно подобную ошибку стремится к нулю.
Ешё раз, см. первый мой пост: если баг не затрагивает тестируемое поведение, то тест не может/не должен обнаруживать косяки. Например, если при тестировании API калькулятора у нас идёт утечка памяти, запись мусора в базу или пропадают кнопки в UI model, но все суммы сходятся, то тест пройден, как бы парадоксально это не звучало.
I>Как ты сможешь по билд-системе и трекеру отделить эффект тестов от эффета любого другого фактора, который возник одновременно с введением тестов ? I>Может просто команда обозлилась и пишет тесты для галочки, а основное время проводит в курилке и обдумывает(== проектирует), как бы решить проблему наименьшим количеством строчек кода. Или так — команда работает по принципу "лишь бы не поломать", а "все тяжелые" фичи зарезаются еще на стадии обсуждения "это сложно, мы не сможем покрыть все тестами, времени надо полгода"
В этом случае вообще никакой разницы от внедрения/не внедрения предложенной методики не будет. Т.е. изначальный вопрос — "I>Как выяснить, что твои тесты действительно полезны ?" решён, ответ — или методика, или тесты в данной команде не работают.
I>То есть, более общая формулировка — на одном проекте ввели мега-процесс и получили срыв сроков, перерасход бюджетов, провальное качество и проект закрылся/заморозился/перешел на другой процесс. На другом сделали тоже самое и получили профит (сроки,бюджеты, качество). Опаньки !
Угу. Как и просил — в одной команде выигрыш есть, в другой — выигрыша нет (считаем, что сравнение происходило в честных условиях и прочие факторы учтены). Или тебя интересовала полезность в попугаях, которая к реальной полезности никак не относится?
I>Итого — одна и та же методология может давать прямо противоположные результаты. Примеров тому тысячи. Отсюда ясно, что вопрос открытый — на какие показатели ориентироваться когда вводишь скажем тесты и тд ?
[Кэп]Зависит от команды[/Кэп]. Самый простой способ — мониторим средний вес story point-а для однотипных задач на протяжении нескольких итераций. Если увеличился (т.е. в итерацию стало укладываться меньше задач) — очевидно, предложенная методика не работает.
Проблема в том, что на анализ как правило забивают и всё сводится к личным предпочтениям по выбору карго-методик
Здравствуйте, Sinix, Вы писали:
I>>А ты тоже по работе по три раза увиливаешь от ответа ? S>Да вроде нигде не увиливал Тыкни носом, плиз.
А писать всякое в ответ на вопрос который никто не задавал ?
I>>Потому что эффективность любого инструмента это не строчка из библии. Качество любой работы можно и нужно проверять. S>Угу. Но только если затраты на проверку качества хоть как-то сопоставимы с выигрышом. Для варианта топикстартера это не так, т.к. S>* методика не автоматизируется и не даёт повторяемых результатов S>* она не проверяет то, что входит в ответственность юнит-тестов S>* чтобы получить хоть какой-то эффект, затраты на ручное тестирование придётся как минимум сравнять с затратами на само тестирование.
S>* есть тонна методик, которые не страдают от перечисленных выше недостатков.
Хоть одну назови, и опиши кратко, как в ней качество тестов проверять.
S>Давай ещё раз: почему при поставленном процессе тестирования нужно изобретать методику мета-тестирования, которая может производиться только вручную?
Объясняю еще раз — качество любой работы должно быть проверяемо. Если ты не можешь этого гарантировать, то, скажем, не ясно, как отделить тесты, которые проверяют моки, от тестов, которые проверяют саму логику.
I>>Есть инструмент — есть ответ на вопросы "какую проблему он решает" и "как проверить, что таки решает" S>Угу, осталось ответить на вопрос "почему мы используем молоток для забивания шурупов?"
Я слабовато понимаю твои аналогии. Ты, кстати, в курсе, что молоток тот же должен быть отцентрирован, иначе ты рискуешь долбануть себя по пальцу ?
S>Потому что качество — характеристика относительная. Чтобы определить лучше-хуже, надо смотреть на изменение ключевых показателей, а не на формальные цифры. Ну а дальше начинается специфичные для каждого проекта вещи, которую в абстрактном споре обсуждать бесполезно.
Ты вероятно плохо понимаешь, что такое качество. Попробуй ответить на этот вопрос и тебе все станет ясно.
I>>Отсюда ясно, что речь про качество тестов. S>С чего бы это? Ты меряешь какую-то левую фигню, которая очень слабо совпадает с зоной ответственности юнит-тестов (если мы про них говорим). Юнит-тесты не могут и не должны определять произвольную поломку в коде, это задача ассертов/стресс-тестирования и прочих методик. Юнит-тесты отвечают за проверку совпадения спецификации и тестируемого поведения.
А я не говорил про произвольную поломку. Для юнит-тестов нужно сломать поведение. Например по спеке эвент кидается не менее и не более одного раза. Закоментил файринг эвента и это проверка теста, если тесты красные, значит все хорошо. Если нет, в тестах косяк.
Если за короткий срок нашлось много таких багов, значит тесты никак не проверяют соответствие спецификации и наблюдаемого поведения.
>Вероятность того, что рандомная поломка выявит именно подобную ошибку стремится к нулю.>
Ога, придумал утверждение и сам же его опроверг, браво.
S>Ешё раз, см. первый мой пост: если баг не затрагивает тестируемое поведение, то тест не может/не должен обнаруживать косяки.
Баг, и ежу понятно, должен явно затрагивать ожидания пользователя. Естественно, тесты html представления, не могут ничего сказать про ошибку в базе данных, просто потому что во время таких тестов нет никакой базы данных.
I>>Как ты сможешь по билд-системе и трекеру отделить эффект тестов от эффета любого другого фактора, который возник одновременно с введением тестов ? I>>Может просто команда обозлилась и пишет тесты для галочки, а основное время проводит в курилке и обдумывает(== проектирует), как бы решить проблему наименьшим количеством строчек кода. Или так — команда работает по принципу "лишь бы не поломать", а "все тяжелые" фичи зарезаются еще на стадии обсуждения "это сложно, мы не сможем покрыть все тестами, времени надо полгода"
S>В этом случае вообще никакой разницы от внедрения/не внедрения предложенной методики не будет. Т.е. изначальный вопрос — "I>Как выяснить, что твои тесты действительно полезны ?" решён, ответ — или методика, или тесты в данной команде не работают.
Вот это классический ответ разных "целителей", "шаманов", "провидцев" и тд.
Между тем всё, что ты делаешь, можно проверить.
S>Угу. Как и просил — в одной команде выигрыш есть, в другой — выигрыша нет (считаем, что сравнение происходило в честных условиях и прочие факторы учтены). Или тебя интересовала полезность в попугаях, которая к реальной полезности никак не относится?
Меня интересует четкий ответ на вопрос, где и как получить профит. Если качество работы проверяемо, то это очень просто. А если нет — то в принципе невозможно, иначе как методом тыка.
S>[Кэп]Зависит от команды[/Кэп]. Самый простой способ — мониторим средний вес story point-а для однотипных задач на протяжении нескольких итераций. Если увеличился (т.е. в итерацию стало укладываться меньше задач) — очевидно, предложенная методика не работает. S>Проблема в том, что на анализ как правило забивают и всё сводится к личным предпочтениям по выбору карго-методик
Я уже спрашивал, как ты различаешь эффекты двух разных факторов.
Вот у меня всё просто — если я, скажем, вижу, что тесты проверяют свои моки, то очевидно, они никакой регрессии не детектят и в принципе не могут детектить. Отсюда ясно, что тестами можно пренебречь.
Здравствуйте, Ikemefula, Вы писали:
S>>* есть тонна методик, которые не страдают от перечисленных выше недостатков. I>Хоть одну назови, и опиши кратко, как в ней качество тестов проверять.
Сорри, но я завязываю, т.к. спор перешёл к стадии "у меня есть точка зрения и я-не-хочу-ничего-слышать", дальше продолжать совсем неинтересно. На вопрос выше я отвечал по крайней мере трижды, если действительно интересно — перечитай, выше ответы есть.
Здравствуйте, Sinix, Вы писали:
S>>>* есть тонна методик, которые не страдают от перечисленных выше недостатков. I>>Хоть одну назови, и опиши кратко, как в ней качество тестов проверять.
S>Сорри, но я завязываю, т.к. спор перешёл к стадии "у меня есть точка зрения и я-не-хочу-ничего-слышать", дальше продолжать совсем неинтересно. На вопрос выше я отвечал по крайней мере трижды, если действительно интересно — перечитай, выше ответы есть.
Ты ни разу не ответил на заданый вопрос. Все твои ответы были про то, для чего нужны тесты и как покрывать код тестами.
Тебе надо было дать внятный ответ на вопрос, как проверить сами тесты.
Здравствуйте, Ikemefula, Вы писали:
I>Тебе надо было дать внятный ответ на вопрос, как проверить сами тесты.
Напоследок, ткскзть.
Пропустить ошибку из-за некорректного теста? Так ошибку можно пропустить по сотне других причин, для лечения этих рисков есть тонна способов дешевле метатестирования — от статистики билд-сервера и до ретро-тестов, когда новый тест автоматом прогоняется на нескольких предыдущих версиях исходников. Вот тут как раз даже ломать ничего не надо — уже известно и когда поломалось, и когда починилось.
Последнее (прогон исправленных тестов на предыдущих версиях) как раз полностью заменяет ручное внесение погрешностей и превосходно автоматизируется. И да, по истории билд-сервера отлично видно, тесты на каких компонентах никогда не срабатывают, а на каких срабатывают через коммит. И то и другое — повод для разбирательства с тестами и с дизайном api. Вот тут как раз метод поломки вручную может пригодиться. Для регулярных проверок он не катит, выше уже писал почему.
Одно но: без учёта реального положения дел в команде, культуры разработки, степени автоматизации и тд и тп о преимуществах-недостатках конкретной методики говорить глупо. Разумеется, в каждом конкретном случае ответ как проверять тесты (и нужно ли это вообще делать) будет свой. Т.е. требовать универсального ответа на все случаи жизни можно ещё долго — всё равно его не будет.
Везде выше я подразумевал типовой для энтерпрайза расклад с работающим qa-менеджером и с устоявшимися методиками тестирования. Для этого случая см ответы выше.
Здравствуйте, Sinix, Вы писали:
S>Последнее (прогон исправленных тестов на предыдущих версиях) как раз полностью заменяет ручное внесение погрешностей и превосходно автоматизируется. И да, по истории билд-сервера отлично видно, тесты на каких компонентах никогда не срабатывают, а на каких срабатывают через коммит. И то и другое — повод для разбирательства с тестами и с дизайном api. Вот тут как раз метод поломки вручную может пригодиться. Для регулярных проверок он не катит, выше уже писал почему.
Вообще говоря тест может и не собраться под предыдущие версии. Старых версий которые аффектают требуемый функционал может быть совсем мало или они уже сами неактуальны и ни собраться ни запуститься не смогут. Но все даже хуже.
Представь себе, ты или ктото другой делаешь рефакторинг xml sax парсера. В ём всегда должны файриться эвенты в определенных условиях.
Нужен тест, чисто на всякий случай, и он есть. Но с ошибкой
it('end fired in the end', () =>{
var fired = true; // опанькиvar sax = new Sax();
sax.on('end', () => { fired = true; })
sax.write(testXml);
assert(fired);
})
Упс — тест всегда срабатывает. Судя по твоим ответам, что бы найти ошибку в этом тесте надо получить статистику от билд-сервера, погонять тест на старых версиях (см выше).
А по моему сначала надо проверить, может ли этот тест вообще быть красным.
Здравствуйте, Ikemefula, Вы писали:
I>Упс — тест всегда срабатывает. Судя по твоим ответам, что бы найти ошибку в этом тесте надо получить статистику от билд-сервера, погонять тест на старых версиях (см выше).
Так это не относится к проверке существующих тестов, это классика по tdd: сначала пишем тест, убеждаемся, что он не работает, затем пишем код до зелёных тестов. Мы вроде как о периодических проверках таким образом говорим.
Ну а чтобы найти ошибку в уже существующих тестах, необязательно ждать пока что-то поломается, достаточно отсеять тесты, которые всегда зелёные и проверять уже их. Это тоже классно автоматизируется — собираем статистику по разумному интервалу, если что-то подозрительное — автоматом заводим тикет на тестирование теста.
Здравствуйте, Ikemefula, Вы писали:
I>ТДД это пример как хорошая методика из за плохого названия трактуется как попало.
У меня постоянно проблемы с применением теории (в частности этой) к практике.
Ну вот, скажем, банальнейшая штука: мы разрабатываем некий API. Это заведомо комфортная для автотестирования ситуация.
Допустим, мы написали себе тест: "метод ProcessPayment должен принимать параметры бла-бла-бла, сохранять инварианты бла-бла-бла и выполняться за менее, чем 200мс".
Это — один из нескольких сотен тестов, которые мы родили в процессе формирования требований к этому API.
Мы несколько раз просмотрели список тестов, убедились в его полноте и непротиворечивости, и в конце концов отдали разработчикам. Welcome to continuos integration, ваши коммиты автоматически проверяются на то, чтобы улучшать заявленные тест кейзы и неухудшать незаявленные.
Через шесть месяцев разработки мы убедились, что уложиться в заявленные 200мс мы не можем никак. Зависим от внешних систем; каждый раз они разные; всё плохо.
Ок. Архитектор сходу предлагает решение: "давайте сделаем наш API асинхронным. Теперь вместо 200 Ok мы будем отвечать 202 Accepted, и вот таким способом клиент сможет поллить нас насчёт реального статуса.
Внезапно нам нужно поменять 60% поверхности нашего API, и переделать несколько сотен тестов, на которые мы потратили столько усилий.
Выглядит как работа в корзинку. Получается, как минимум архитектуру системы нужно спроектировать до тестов. А ещё желательно иметь прототип реализации. Ну, если нам жалко этих человеко-месяцев, потраченных на подготовку заведомо непроходимых тестов.
Если же мы отойдём от API в сторону UI, то внезапно окажется, что автотесты прекрасно пропускают неприемлемые факапы (вроде кнопки, уехавшей за пределы видимой части окна), зато катастрофически чувствительны к маловажным для пользователя деталям (типа один шаг визарда распался на два). Получается, что с помощью TDD UI разрабатывать вообще невозможно — это как уловить сходство до написания портрета.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>У меня постоянно проблемы с применением теории (в частности этой) к практике. S>Ну вот, скажем, банальнейшая штука: мы разрабатываем некий API. Это заведомо комфортная для автотестирования ситуация. S>Допустим, мы написали себе тест: "метод ProcessPayment должен принимать параметры бла-бла-бла, сохранять инварианты бла-бла-бла и выполняться за менее, чем 200мс".
Такие тесты это не совсем тдд. Там нужны функциональные тесты, то есть просто проверка сценариев. Если вводить граничные условия, время и тд, то получается хрень которую невозможно майнтейнить.
S>Ок. Архитектор сходу предлагает решение: "давайте сделаем наш API асинхронным. Теперь вместо 200 Ok мы будем отвечать 202 Accepted, и вот таким способом клиент сможет поллить нас насчёт реального статуса. S>Внезапно нам нужно поменять 60% поверхности нашего API, и переделать несколько сотен тестов, на которые мы потратили столько усилий. S>Выглядит как работа в корзинку. Получается, как минимум архитектуру системы нужно спроектировать до тестов. А ещё желательно иметь прототип реализации. Ну, если нам жалко этих человеко-месяцев, потраченных на подготовку заведомо непроходимых тестов.
Вообще говоря да. Как минимум, нужно знать какую вычислительную модель ты будешь использовать. В сложных случаях нужно спроектировать до начала написания тестов. Тесты помогают уточнить дизайн.
Похожая проблема — когда ты не знаешь, какая будет вычислительная модель.
S>Если же мы отойдём от API в сторону UI, то внезапно окажется, что автотесты прекрасно пропускают неприемлемые факапы (вроде кнопки, уехавшей за пределы видимой части окна), зато катастрофически чувствительны к маловажным для пользователя деталям (типа один шаг визарда распался на два). Получается, что с помощью TDD UI разрабатывать вообще невозможно — это как уловить сходство до написания портрета.
Да, есть такое. Здесь ТДД не работает. Максимум, что можно добиться, это примерно так — проверить, что тот же html контрола после выполнения операции изменится определенным образом.
Собственно ты показал, то о чем я и говорил. ТДД нужен для унутреннего дизайна модулей, компонентов. Если надо слать реквесты, мерять время, следить за UI, то ничего путного не выйдет.
Собтсвенно Кент Бек как раз про это и говорит, ТДД это не всеобъемлющая методология.
Здравствуйте, Шахтер, Вы писали:
Ш>Следующий шаг -- обратное тестирование. Мы берем исходный код и целенапрвленно вводим в него дефекты. И запускаем тесты. Ш>Если тесты не улавливают наличие дефектов, то тест-систему корректируем.
это обычный mutation testing(список фреймворков внизу http://en.wikipedia.org/wiki/Mutation_testing), по опыту мало полезная штука. от того что к коду были написаны идеальные тесты покрытие реальных сценариев сильно не увеличиться, софт надежнее не станет.
это идея из той же серии что хаскеловские примочки аля автоматические тесты, которым границы аргументов просто задаешь, а они и в хвост и в гриву.
реальный толк от этого только при тестировании какой нибудь низкоуровневой функции вроде извлечения квадратного корня,
но поскольку такие вещи часто дергаются с разными аргументами, то баги и так видно даже без тестов обычно.
Здравствуйте, Ikemefula, Вы писали:
I>Такие тесты это не совсем тдд.
Простите, но тогда никакого ТДД вообще не существует.
Вся его идея — выражать все требования в тестах. I>Похожая проблема — когда ты не знаешь, какая будет вычислительная модель.
Я не вполне уверен, что понимаю, что такое "вычислительная модель", но интуитивно чувствую, что это то же самое.
Грубо говоря, если мы проектируем систему общественного транспорта, то ТДД не даст нам перейти от light train к hyperloop.
Я, как фанат hyperloop, склонен игнорировать техники, не приводящие к его появлению
I>Да, есть такое. Здесь ТДД не работает. Максимум, что можно добиться, это примерно так — проверить, что тот же html контрола после выполнения операции изменится определенным образом.
Угу. И это умрёт при первой же смене скина.
I>Собственно ты показал, то о чем я и говорил. ТДД нужен для унутреннего дизайна модулей, компонентов. Если надо слать реквесты, мерять время, следить за UI, то ничего путного не выйдет.
Ну. то есть он нужен, когда дизайн уже более-менее есть.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
I>>Такие тесты это не совсем тдд. S>Простите, но тогда никакого ТДД вообще не существует. S>Вся его идея — выражать все требования в тестах.
На самом деле не все, а только на определенном уровне.
I>>Похожая проблема — когда ты не знаешь, какая будет вычислительная модель. S>Я не вполне уверен, что понимаю, что такое "вычислительная модель", но интуитивно чувствую, что это то же самое. S>Грубо говоря, если мы проектируем систему общественного транспорта, то ТДД не даст нам перейти от light train к hyperloop. S>Я, как фанат hyperloop, склонен игнорировать техники, не приводящие к его появлению
Да, tdd завязан на рефакторинг. Смена вычислительной модели через рефакторинг возможна, но на практике ошалеешь сильно раньше чем получишь результат согласно требованиям и ограничениям.
I>>Собственно ты показал, то о чем я и говорил. ТДД нужен для унутреннего дизайна модулей, компонентов. Если надо слать реквесты, мерять время, следить за UI, то ничего путного не выйдет. S>Ну. то есть он нужен, когда дизайн уже более-менее есть.
Почти так и есть. Если ты не можешь представить себе что такое скажем комбинатор парсеров, то рефакторить в этом направлении мягко говоря затруднительно.
ТДД работает при уточнении деталей дизайна. То есть, сначала нужно решить задачу, а именно представить как будет работаь новая система. Потом решить вторую задачу — преобразовать старый код в новую вычислительную модель. И здесь куча нюансов.
Например, старая модель была синхронной, а новая асинхронная. Всякие вещи навроде промисов, авайтов помогают с переходом к асинхронной модели, но есть всякие скрытые проблемы, неочевидные на первый взгляд — например, внезапно появляются разделяемые ресурсы, поскольку асинхронщина это фактически кооперативная многозадачность и последовательное выполнение надо обеспечивать руками. Если пытаться использовать всякие лифтинги, то оказывается так, что надо четко знать, что и когда лифтить, а именно — лифтить только там где используется само значение. Если лифтить всё и везде, то может оказаться так, что прога работает, но операции выполняются в разы дольше. Сразу же появляются проблемы с контекстами выполнения — когда пришел колбек старый контекст может быть разрушен и это нормально.
Другой пример — модель была эвент-дривен рич, а новая обычная синхронная навроде анемик. Переход от одной к другой это адский ад.
Ш>А теперь серьёзно. Существует практический аспект обратного теста Тьюринга. Ш>Это методика обратного тестирования. Я её использую при разработки ответственного софта. Ш>Суть её в следующем. Мы пишем некоторый софтварный компонент. Ш>Далее мы пишем тесты для него. Прогоняем. Ш>Большинство программистов на этой стадии останавливаются. Но останавливаться не надо. Ш>Следующий шаг -- обратное тестирование. Мы берем исходный код и целенапрвленно вводим в него дефекты. И запускаем тесты. Ш>Если тесты не улавливают наличие дефектов, то тест-систему корректируем.
Вообще по классике TDD первыми пишутся тесты, тестирующие все возможные сценарии работы функционала. Тесты разумеется сразу фэйлятся за отсутствием тестируемого функционала. А потом уже реализуется функционал, который считается рабочим когда тесты успешно срабатывают.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Ikemefula, Вы писали:
I>ТДД работает при уточнении деталей дизайна. То есть, сначала нужно решить задачу, а именно представить как будет работаь новая система. Потом решить вторую задачу — преобразовать старый код в новую вычислительную модель. И здесь куча нюансов.
А как это будет выглядеть в реальности?
Например я собираюсь разрабатывать что-то типа StackOverflow. У меня уже есть эскиз дизайна и я знаю что это будет ASP.NET MVC и SQL Server.
В какой момент начинать писать тесты, так чтобы потом не было мучительно больно, когда я захочу дизайн поменять?
Здравствуйте, gandjustas, Вы писали:
I>>ТДД работает при уточнении деталей дизайна. То есть, сначала нужно решить задачу, а именно представить как будет работаь новая система. Потом решить вторую задачу — преобразовать старый код в новую вычислительную модель. И здесь куча нюансов.
G>А как это будет выглядеть в реальности? G>Например я собираюсь разрабатывать что-то типа StackOverflow. У меня уже есть эскиз дизайна и я знаю что это будет ASP.NET MVC и SQL Server. G>В какой момент начинать писать тесты, так чтобы потом не было мучительно больно, когда я захочу дизайн поменять?
В TDD нет ничего про тесты уровня приложения. Скажем, Кет Бек ничего конкретного не говорит.
В реальности это выглядит так — надо быть в курсе того, как делать дизайн, который можно будет сменить. После того, как ты решишь эту задачу, можно начинать писать тесты. Но это будут тесты в основном компонентов, а не приложения.
Здравствуйте, ononim, Вы писали:
Ш>>Если тесты не улавливают наличие дефектов, то тест-систему корректируем. O>Вообще по классике TDD первыми пишутся тесты, тестирующие все возможные сценарии работы функционала. Тесты разумеется сразу фэйлятся за отсутствием тестируемого функционала. А потом уже реализуется функционал, который считается рабочим когда тесты успешно срабатывают.
Есть несколькол нюансов,
1 тесты в ТДД в корне неверно понимать, как тесты.
Хотя тесты пишутся, но их назначение это спецификация. Это самая большая дыра в ТДД, Бертран Мейер, например, утверждает что тесты вместо спецификации это просто баловство. Сам Кент Бек утверждает, что тесты в ТДД мало чем похожи на юнит-тесты, хотя и очень похожи
2 ТДД это скорее test driven design
TDD оно изначально про проектирование, а не разработку, тестирование или покрытие тестами и тд.
3 Тесты в тдд предназначены быть инструментом разработчика и никак не тестера, архитектора, тим-лида, продукт-овнера и тд и тд и тд. Скажем, девелопер никогда не работает в скопе всего приложения. Он занят проектированием отдельных компонентов унутре.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>ТДД работает при уточнении деталей дизайна. То есть, сначала нужно решить задачу, а именно представить как будет работаь новая система. Потом решить вторую задачу — преобразовать старый код в новую вычислительную модель. И здесь куча нюансов.
G>>А как это будет выглядеть в реальности? G>>Например я собираюсь разрабатывать что-то типа StackOverflow. У меня уже есть эскиз дизайна и я знаю что это будет ASP.NET MVC и SQL Server. G>>В какой момент начинать писать тесты, так чтобы потом не было мучительно больно, когда я захочу дизайн поменять?
I>В TDD нет ничего про тесты уровня приложения. Скажем, Кет Бек ничего конкретного не говорит.
I>В реальности это выглядит так — надо быть в курсе того, как делать дизайн, который можно будет сменить. После того, как ты решишь эту задачу, можно начинать писать тесты. Но это будут тесты в основном компонентов, а не приложения.
Каких компонентов? В какой момент появляются эти "компоненты"?
Например в ASP.NET MVC контроллеры — это компоненты? Роуты — компоненты? Фильтры — компоненты?
I>>В реальности это выглядит так — надо быть в курсе того, как делать дизайн, который можно будет сменить. После того, как ты решишь эту задачу, можно начинать писать тесты. Но это будут тесты в основном компонентов, а не приложения.
G>Каких компонентов? В какой момент появляются эти "компоненты"?
Как только тебе хочется написать какой нибудь код. Вместо этого пишешь тест.
G>Например в ASP.NET MVC контроллеры — это компоненты? Роуты — компоненты? Фильтры — компоненты?
Здравствуйте, Ikemefula, Вы писали:
I>Есть несколькол нюансов, I>1 тесты в ТДД в корне неверно понимать, как тесты.
I> Хотя тесты пишутся, но их назначение это спецификация. Это самая большая дыра в ТДД, Бертран Мейер, например, утверждает что тесты вместо спецификации это просто баловство. Сам Кент Бек утверждает, что тесты в ТДД мало чем похожи на юнит-тесты, хотя и очень похожи
Спецификация какая именно? Если внешняя (что код должен делать независимо от его структуры), то по современной терминологии обеспечение этого называется behavior-driven development (BDD), а не TDD. TDD же "осталось" отвечать за внутренние тесты, насколько оно вообще может быть адекватно определено.
I>2 ТДД это скорее test driven design I> TDD оно изначально про проектирование, а не разработку, тестирование или покрытие тестами и тд.
I>3 Тесты в тдд предназначены быть инструментом разработчика и никак не тестера, архитектора, тим-лида, продукт-овнера и тд и тд и тд.
Разве что в том смысле, что это его дело — определить, как именно покрыть свой код, чтобы обеспечить свою ответственность за него. Но почему для этого исключать ответственность вышестоящих?
Здравствуйте, Шахтер, Вы писали:
Ш>А теперь серьёзно. Существует практический аспект обратного теста Тьюринга. Ш>Это методика обратного тестирования. Я её использую при разработки ответственного софта. Ш>Суть её в следующем. Мы пишем некоторый софтварный компонент. Ш>Далее мы пишем тесты для него. Прогоняем. Ш>Большинство программистов на этой стадии останавливаются. Но останавливаться не надо. Ш>Следующий шаг -- обратное тестирование. Мы берем исходный код и целенапрвленно вводим в него дефекты. И запускаем тесты. Ш>Если тесты не улавливают наличие дефектов, то тест-систему корректируем.
Я об этом давно писал, например, тут. В свою очередь, с моей стороны это переформулировка подходов, которые использовались при разработке военной и т.п. техники и соответственно были применены после постановки вопросов "а откуда уверенность, что оно просто не врёт, говоря, что всё хорошо?"
Но в моей методике дефекты в основном вводятся не в код (хотя и это можно сделать — выставляя через тест-окружение команды "сломаться тут"), а в задания теста. Если тест типа "сделали 10 нажатий мышой в конкретных местах и проверили посылку файла", то инверсия — пропустить одно нажатие и убедиться, что файл не посылается. Необходимости делать такие точки пробной поломки именно в рабочем коде я пока не видел.
Ш>Для проведения теста Тьюринга нужно грамотно выбрать группу экспертов. Иначе это будет профанация. Ш>Как это сделать? А очень просто, с помощью обратного теста Тьюринга. Т.е. если группа экспертов не может отличить человека от компьютера, то мы её выгоняем.
Ну так оно в общем и делается, независимо от того, что проверяется. Странно, что это где-то ещё приходится явно формулировать. Вот что обычно требует уточнения — это требования к надёжности такого детектирования, они берутся из теории мат. статистики.
Здравствуйте, jazzer, Вы писали:
Ш>>Тесты валится не должны. Они валится могут, если ты сделал ошибку в коде.
J>Так в том и дело. Ты стартуешь с (предположительно) правильно написанного кода и только потом пишешь к нему тесты. J>А в TDD стартуют с неправильного (или вообще отсутствующего) кода. Т.е. правильного кода еще нет, а тесты уже есть, и они все не срабатывают. И твоя цель — сделать тесты срабатывающими.
И это работает только в индусском оффшоре А почему? А потому, что если у тебя уже есть правильный код, а спецификация поменялась, тебе приходится или плевать на принципы TDD и заводить тест к уже работающему коду, или явно ломать код, чтобы убедиться, что тест его проверяет (то, что как раз описал Шахтёр). Например, тебе добавили в спеку "должно работать с числами до миллиарда". Ты задумчиво лезешь в код, видишь везде int64_t и начинаешь гадать, что сделать: отрапортовать, что всё и так работает? переписать весь код на short, чтобы поломалось, затем обратно, чтобы починить?
А почему индусском оффшоре — потому что только там могут позволить себе выкинуть весь код, чтобы написать с нуля, зато строго по TDD
J>И ты думаешь о достаточности тестов до того, как начнешь писать код (т.е. фактически формулируешь требования к коду и излагаешь их на языке тестов). J>И тесты становятся своего рода документацией к (ненаписанному еще) коду, показывая, что должно срабатывать, а что не должно.
После чего законно вешаешь над рабочим местом табличку "Я — бог!" И все с этим согласны, потому что простой смертный не может делать сколь-нибудь сложный код без нескольких попыток написания (и к которому тесты будут написаны уже после того, как код заработал).
Впрочем, задача тривиально решается после этого с использованием любого клана norton commander. После того, как всё сделано, создаём пустое репо, кладём туда вычищенные тесты (после 30-й итерации, когда наконец поняли, как же код должен и может работать, с учётом всех тараканов библиотек). Коммитим. Дальше в течение пары дней в перерывах между фишками и контактиком лениво делаем F5 на файл, коммитим, радуемся сокращению количества красных огней на пару штук и повторяем цикл. Первая часть, когда код реально писался, списывается на R&D работы. Вторая — типа таки наконец писали код. Топ-менеджмент радуется отчёту о покрытии разработки нормами TDD на 146% и заказывает себе новый Q7 взамен разбитого по пьяни, а программист получает премию по перевыполнению KLOC/day. Для такой цели — да, TDD рулит.
Здравствуйте, мыщъх, Вы писали:
М>это очень древняя методика. она использовалась еще когда ассемблера не было.
М>в программу умышленно вносится определенное число ошибок. пускай для определенности сто. если в результате тестирования выявлено только 50, то это позволяет нам оценить качество тестирования и кол-во скрытых ошибок в релизе.
О! В варианте проверить и сам отдел QA/QC таким образом — да, это надо отметить особо.
Хоть и старое, но используется крайне редко.
Здравствуйте, Ikemefula, Вы писали:
I>ТДД это не написание системы тестов. ТДД оно про проектирование. Знать код не нужно, но вот представлять, как решается задача очень даже нужно. Скажем, нужно хотя бы представлять более-менее детально вычислительную модель.
Могу тут только присоединиться к комментариям Sinclair. Как известно, только с третьей версии любая программа становится пригодной к использованию При этом она может пройти принципиальную переделку дизайна, и не одну. Поэтому любая методика, рассчитанная на то, что дизайн известен заранее, работать не будет.
I>ТДД это пример как хорошая методика из за плохого названия трактуется как попало.
Нет. Это методика, которая заведомо не работает за пределами крайне узкой области ситуаций, когда кода ещё нет, а дизайн известен на 100% до мельчайших уровней. Как только ставится вопрос о её применении на практике, какие-то её постулаты отменяются и заменяются на более реальные. Так как методов это сделать — бразиллион и маленькая тележка, получается, что те, кто называют свою реальную методику "TDD", имеют в виду свою специфическую адаптацию. Поэтому и трактовка "как попало".
А название у неё как раз 100% адекватное
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Ikemefula, Вы писали:
I>>ТДД это не написание системы тестов. ТДД оно про проектирование. Знать код не нужно, но вот представлять, как решается задача очень даже нужно. Скажем, нужно хотя бы представлять более-менее детально вычислительную модель.
N>Могу тут только присоединиться к комментариям Sinclair. Как известно, только с третьей версии любая программа становится пригодной к использованию При этом она может пройти принципиальную переделку дизайна, и не одну.
Переделки дизайна это нормально. Главное что нужно в ТДД это представлять направление движения.
I>>ТДД это пример как хорошая методика из за плохого названия трактуется как попало.
N>Нет. Это методика, которая заведомо не работает за пределами крайне узкой области ситуаций, когда кода ещё нет, а дизайн известен на 100% до мельчайших уровней.
На 100% до мельчайших уровней будет известно только перед релизом. Ты точно про ТДД ?
Здравствуйте, Ikemefula, Вы писали:
I>>>ТДД это не написание системы тестов. ТДД оно про проектирование. Знать код не нужно, но вот представлять, как решается задача очень даже нужно. Скажем, нужно хотя бы представлять более-менее детально вычислительную модель. N>>Могу тут только присоединиться к комментариям Sinclair. Как известно, только с третьей версии любая программа становится пригодной к использованию При этом она может пройти принципиальную переделку дизайна, и не одну. I>Переделки дизайна это нормально. Главное что нужно в ТДД это представлять направление движения.
Тогда расскажи подробнее, как по-твоему и по-бековски (не смешивая эти два варианта) реагировать на _изменение_ этого "направления движения".
I>>>ТДД это пример как хорошая методика из за плохого названия трактуется как попало. N>>Нет. Это методика, которая заведомо не работает за пределами крайне узкой области ситуаций, когда кода ещё нет, а дизайн известен на 100% до мельчайших уровней. I>На 100% до мельчайших уровней будет известно только перед релизом. Ты точно про ТДД ?
Да, точно про TDD. Неважно, речь про полный релиз или промежуточный релиз любого субкомпонента, но по строгой TDD дизайн должен быть известен до написания кода.
Здравствуйте, netch80, Вы писали:
I>>Переделки дизайна это нормально. Главное что нужно в ТДД это представлять направление движения.
N>Тогда расскажи подробнее, как по-твоему и по-бековски (не смешивая эти два варианта) реагировать на _изменение_ этого "направления движения".
У Бека именно это не раскрывается. Можно делать как все остальное — писать тесты, менять тесты и добиваться, что бы код их проходил. Но вообще лучше сделать чтото навроде разведки — выяснить, что именно должно поменяться и каким образм и написать просто черновой вариант, мжно даже без компиляния. Далее станет понятно, как именно все меняется и после этого становится понятно, как писать тесты.
I>>>>ТДД это пример как хорошая методика из за плохого названия трактуется как попало. N>>>Нет. Это методика, которая заведомо не работает за пределами крайне узкой области ситуаций, когда кода ещё нет, а дизайн известен на 100% до мельчайших уровней. I>>На 100% до мельчайших уровней будет известно только перед релизом. Ты точно про ТДД ?
N>Да, точно про TDD. Неважно, речь про полный релиз или промежуточный релиз любого субкомпонента, но по строгой TDD дизайн должен быть известен до написания кода.
Нет, ТДД это инструмент создания дизайна. Изначально нужна только вычислительная модель. Скажем, ты вспотеешь рефакторить lr в ll парсер. Более того, обычный recursive descent рефакторить в комбинаторы парсеров тоже не самая простая задача, хотя и возможная.
Здравствуйте, Sinix, Вы писали:
S>На мой взгляд, это шаманство в самом плохом смысле слова. Ну, как гадать на погоду по мокрому пальцу, когда рядом стоит метеостанция.
Если уж подбирать аналогию, то она будет выглядеть так. Видим, что приближается дождь, и накрываем станцию колпаком. Если из отчёта системы получаем, что метеостанция сказала, что идёт дождь — значит, или система врёт, что получила данные в том числе и от этой станции, или сама станция работает не так, как положено.
В варианте Шахтёра делается, считаем, чуть иначе — в станции выдёргивается датчик воды в накопителе. Но результат должен быть тем же — если она не сказала, что дождя нет, что-то происходит не так.
S>Уже есть стабильные, автоматизируемые, повторяемые методики тестирования. Ты сам наверно знаешь, просто перечислю:
S>* Для анализа покрытия тестами есть само покрытие тестами плюс поиск непокрытых вариантов через code flow analysis (см chess/pex). S>* Для случайных ошибок-опечаток — компилятор, статический анализ, code contracts, валидация аргументов и ассерты. S>* Для поиска неочевидных ошибок и нарушений любых инвариантов — всё те же ассерты и инструментирование через AOP (postsharp или инварианты в CodeContracts). Этот пункт великолепно уживается с отладочными сборками, интеграционными и ui-тестами. И, в отличие от юнит-тестов, как раз позволяют тестировать детали реализации. S>* Для софта с экстремальными требованиями по надёжности есть полная статическая верификация и генерация кода по верифицированной матмодели + дифф-тесты по эталону.
S>Что может дать нового методика "ломаем код, запускаем" (aka мета-тестирование) с учётом всего вышеперечисленного?
Она может дать:
1. Обнаружение проблем значительно дешевле, чем описанные методики.
2. Обнаружение проблем в самих применяемых инструментах.
Если ты не понял контекст — уточняю, что речь не идёт о функциональных тестах самого нижнего уровня, известных также как юнит-тесты. Там такое нужно очень редко (хотя имеет смысл, если придуманы какие-то кастомные сложные условия проверки, логика которых не прозрачна с первого взгляда). Описанная методика — для тестов более высокого уровня, которые в некоторых традициях называются интеграционными и проверяют не одну функцию или даже модуль, а целые компоненты.
Кроме того, она (по крайней мере в моём варианте, а не варианте Шахтёра) является прямой проекцией логики BDD на средства тестирования, добавляя не покрытый ранее случай. Например, если у системы на входе A, на выходе должно быть B. А если на входе A+, на выходе должно быть B-. Обычно из такой постановки делают только тесткейс "A => B". Но почему не делают тесткейс "!(A+ => B)"? Ведь это тоже однозначно следует из условий. Но почему-то ограничиваются только положительными условиями. Если ты знаешь, что A+ => B-, то можешь написать для него прямой тест, ok. Но есть ситуации, когда точный ответ заранее в принципе неизвестен (определяется случайностью или слишком сложно вычисляемыми факторами), зато известно, чем он не может быть. Тогда естественная формулировка условия — отрицательная. И вот тут его реализовать поможет инверсия: вложенный тест упал — значит, внешнее условие проверено (особенно, если уточнить, как именно он упал).
S>Ну ок, допустим, тесты упали. Значит ли это что всё хорошо и тесты корректны? Нифига, нет никаких гарантий, что тесты не пропустят любую другую ошибку.
Гарантий нет, как и с любыми другими тестами. Тесты покрывают ничтожную часть данных и ситуаций, говорит кэп. Но по ним тот, кто знает код, может организовать проверку узких мест и граничных условий. Точно так же и с инверсиями.
S>В любом из вариантов мы узнаем только одно — надо разбираться в коде, чтобы определить где косяк: в тестах, в коде или в техзадании. Сорри, но то же самое известно и так, без лишних приседаний.
На практике инверсии мне помогали несколько раз выявлять проблемы, которые прямыми тестами интеграционного уровня не опознавались, а тотальное покрытие по названным тобой методикам было невозможно по недостатку ресурсов. Соответственно "известно" оно не было до срабатывания контроля.
S>О чём и было сказано выше: любая попытка при помощи юнит-тестов "заглянуть глубже" публичного API неизменно приводит к тому, что расходы на тестирование перекрывают выигрыш на порядок.
Я не понял связи описанной методики с юнит-тестами, тем более, "заглядывающими ниже".
S>tzlom S> Едет ли машина у которой не горят фары? S>[/q] S>Так вот, тестирование через поломку кода нифига не поможет найти нерабочие фары.
Оно поможет найти другое: что фары горят не от того, что их явно включили, а от того, что что-то закоротило, или перепутали провода и подключили их к питанию инжектора, или ещё от чего-то аналогичного. На каком-то из сайтов анекдотов была история, как на Ладе загорался дальний, когда выжато сцепление — это как раз из таких ситуаций.
И спроси любого автомеханика, обратит ли он внимание на то, что у машины загорелись фары, когда только включено зажигание. Даже если это машина из Европы с DRL, такого не должно быть, хотя бы пока двигатель не завёлся.
S> Максимум, поймать ДПС-ника, пропустившего машину, сдающую задним ходом с негорящим белым. Ну и нафига оно надо производителю?
А если кто-то отвечает за систему в комплексе, а не только машину?
Здравствуйте, Ikemefula, Вы писали:
I>>>Переделки дизайна это нормально. Главное что нужно в ТДД это представлять направление движения. N>>Тогда расскажи подробнее, как по-твоему и по-бековски (не смешивая эти два варианта) реагировать на _изменение_ этого "направления движения". I>У Бека именно это не раскрывается.
Именно! Потому что его методика в принципе не предусматривает ситуации типа "код уже есть, работает, спецификация поменялась/уточнилась". Как только такое возникает — мы выходим за пределы методики, и надо ставить костыли какого-то вида, но в любом случае костыли.
А всё потому, что он единственным методом проверки теста выбрал то, что кода ещё нет, и тест не проходит. При этом, заметь, ни слова не сказано ни про адекватность кода задаче, ни про адекватность самого теста. Код может состоять из одного switch с проверкой условий, перечисленных в тестах. Тест может не проверять целевое условие вообще. Думаешь, я утрирую? Сравни варианты:
и тут вдруг оказывается, что из-за сверхпутаных установок компиляции почему-то именно в файле, куда перенесли assert(), оказалось #define NDEBUG; а в случае assertEquals() из-за опять же путаных настроек в каком-нибудь setUp() сбился метод сверки, тупо выдавая true на все сравнения на равенство, и проблемы тупо замалчиваются. Ты допишешь код, и у тебя тест вдруг заработал, а с чем ты сравнивал — ему пофиг, оно и 3 и 8 приняло бы в качестве ответа.
И это ещё относительно простой код и простые проверки. А у меня как-то было, что из-за кривого стартапа включилось в цепочку два экземпляра компоненты параллельно(!)
Суммируя — если у тебя после сработавшего теста хоть что-то изменилось (начиная от версии ядра на тестовой машине, продолжая апгрейдом модуля unittest и вплоть до перегруппировки тестов по файлам) — у тебя есть шансы, что тесты не заработают как следует. А обычная проверка срабатывает только на новые false negative, но не на false positive.
I> Можно делать как все остальное — писать тесты, менять тесты и добиваться, что бы код их проходил. Но вообще лучше сделать чтото навроде разведки — выяснить, что именно должно поменяться и каким образм и написать просто черновой вариант, мжно даже без компиляния. Далее станет понятно, как именно все меняется и после этого становится понятно, как писать тесты.
Ну о чём я и говорил в предыдущем. Назовём эту методику "Нортон в помощь". Перемещаем вбок всё и восстанавливаем далее по частям. Только вот я боюсь, что после 5-го повторения на большом проекте тебя закидают помидорами... Инверсии дешевле и надёжнее, и автоматизируются. Прогонять их раз в сутки обычно более чем достаточно.
N>>Да, точно про TDD. Неважно, речь про полный релиз или промежуточный релиз любого субкомпонента, но по строгой TDD дизайн должен быть известен до написания кода. I>Нет, ТДД это инструмент создания дизайна.
По описанному тобой это скорее инструмент типа "сделаю дизайн неизменяемым. дорого."
I> Изначально нужна только вычислительная модель. Скажем, ты вспотеешь рефакторить lr в ll парсер. Более того, обычный recursive descent рефакторить в комбинаторы парсеров тоже не самая простая задача, хотя и возможная.
У меня задачи совсем другого рода. Всякие системы управления и мониторинга. Там дизайн нижнего уровня может меняться радикально, но поведение типа "если сработали датчики Q1 и Q14, не позже чем через 2 секунды должно быть отправлено сообщение F176, и повторяться каждые 1-3 секунд до изменения условия" остаётся неизменным. Вот такие поведения и проверяются.
Здравствуйте, netch80, Вы писали:
N>Суммируя — если у тебя после сработавшего теста хоть что-то изменилось (начиная от версии ядра на тестовой машине, продолжая апгрейдом модуля unittest и вплоть до перегруппировки тестов по файлам) — у тебя есть шансы, что тесты не заработают как следует. А обычная проверка срабатывает только на новые false negative, но не на false positive.
Да, всё так.
N>Ну о чём я и говорил в предыдущем. Назовём эту методику "Нортон в помощь". Перемещаем вбок всё и восстанавливаем далее по частям. Только вот я боюсь, что после 5-го повторения на большом проекте тебя закидают помидорами... Инверсии дешевле и надёжнее, и автоматизируются. Прогонять их раз в сутки обычно более чем достаточно.
Я не сильно в курсе терминов, что значит инверсии ?
N>>>Да, точно про TDD. Неважно, речь про полный релиз или промежуточный релиз любого субкомпонента, но по строгой TDD дизайн должен быть известен до написания кода. I>>Нет, ТДД это инструмент создания дизайна.
N>По описанному тобой это скорее инструмент типа "сделаю дизайн неизменяемым. дорого."
Да, в случае с говнотестами так и получается. Их очень тяжело майнтейнить. В тдд нужны в первую очередь тесты сценариев.
N>У меня задачи совсем другого рода. Всякие системы управления и мониторинга. Там дизайн нижнего уровня может меняться радикально, но поведение типа "если сработали датчики Q1 и Q14, не позже чем через 2 секунды должно быть отправлено сообщение F176, и повторяться каждые 1-3 секунд до изменения условия" остаётся неизменным. Вот такие поведения и проверяются.
То есть, это просто тесты сценариев. Чем же тебе тдд не нравится ?
Здравствуйте, netch80, Вы писали:
N>Если ты не понял контекст — уточняю, что речь не идёт о функциональных тестах самого нижнего уровня, известных также как юнит-тесты. Там такое нужно очень редко (хотя имеет смысл, если придуманы какие-то кастомные сложные условия проверки, логика которых не прозрачна с первого взгляда). Описанная методика — для тестов более высокого уровня, которые в некоторых традициях называются интеграционными и проверяют не одну функцию или даже модуль, а целые компоненты.
Не совсем понятно, что ты понимаешь под функциональными, юнит-тестами и интеграциооными. И что значит самый нижний уровень ? Поясни пожалуйста.
Здравствуйте, Ikemefula, Вы писали:
N>>Ну о чём я и говорил в предыдущем. Назовём эту методику "Нортон в помощь". Перемещаем вбок всё и восстанавливаем далее по частям. Только вот я боюсь, что после 5-го повторения на большом проекте тебя закидают помидорами... Инверсии дешевле и надёжнее, и автоматизируются. Прогонять их раз в сутки обычно более чем достаточно. I>Я не сильно в курсе терминов, что значит инверсии ?
Это изменения, которые принуждают код выдать неподходящий результат (а тест, соответственно, должен сломаться), но чтобы код теста или как минимум его проверочный код не проверял их. (Генерирующий входные данные — может и часто должен знать.)
Конкретная реализация задания этих изменений — по обстановке. Главное — повторюсь, отсутствие знания факта такого изменения в реализующем и проверяющем коде (в моём варианте), в тестирующем коде — полностью (у Шахтёра).
N>>По описанному тобой это скорее инструмент типа "сделаю дизайн неизменяемым. дорого." I>Да, в случае с говнотестами так и получается. Их очень тяжело майнтейнить. В тдд нужны в первую очередь тесты сценариев.
См. ниже.
N>>У меня задачи совсем другого рода. Всякие системы управления и мониторинга. Там дизайн нижнего уровня может меняться радикально, но поведение типа "если сработали датчики Q1 и Q14, не позже чем через 2 секунды должно быть отправлено сообщение F176, и повторяться каждые 1-3 секунд до изменения условия" остаётся неизменным. Вот такие поведения и проверяются. I>То есть, это просто тесты сценариев.
Не только. Главное, что покрытие такими тестами идёт сверху, а не снизу. Но в заметной мере ты прав, их существенная цель — проверить логику каждого уровня, а не реализацию.
I> Чем же тебе тдд не нравится ?
1. Как я уже говорил, обычно TDD соотносится именно с юнит-тестами, то есть (в стандартных терминах) тестах конечных функций и методов. Теме соответствия спецификациям и порождённых из тех сценариев посвящён BDD.
2. Я уже подробно расписывал, чем.
Здравствуйте, Ikemefula, Вы писали:
N>>Если ты не понял контекст — уточняю, что речь не идёт о функциональных тестах самого нижнего уровня, известных также как юнит-тесты. Там такое нужно очень редко (хотя имеет смысл, если придуманы какие-то кастомные сложные условия проверки, логика которых не прозрачна с первого взгляда). Описанная методика — для тестов более высокого уровня, которые в некоторых традициях называются интеграционными и проверяют не одну функцию или даже модуль, а целые компоненты.
I>Не совсем понятно, что ты понимаешь под функциональными, юнит-тестами и интеграциооными. И что значит самый нижний уровень ? Поясни пожалуйста.
Прости, что непонятно в написанном выше?? Я даже квотинг привожу полностью.
Здравствуйте, netch80, Вы писали:
N>>>Если ты не понял контекст — уточняю, что речь не идёт о функциональных тестах самого нижнего уровня, известных также как юнит-тесты. Там такое нужно очень редко (хотя имеет смысл, если придуманы какие-то кастомные сложные условия проверки, логика которых не прозрачна с первого взгляда). Описанная методика — для тестов более высокого уровня, которые в некоторых традициях называются интеграционными и проверяют не одну функцию или даже модуль, а целые компоненты.
I>>Не совсем понятно, что ты понимаешь под функциональными, юнит-тестами и интеграциооными. И что значит самый нижний уровень ? Поясни пожалуйста.
N>Прости, что непонятно в написанном выше?? Я даже квотинг привожу полностью.
Здравствуйте, netch80, Вы писали:
I>> Чем же тебе тдд не нравится ?
N>1. Как я уже говорил, обычно TDD соотносится именно с юнит-тестами, то есть (в стандартных терминах) тестах конечных функций и методов. Теме соответствия спецификациям и порождённых из тех сценариев посвящён BDD.
Сам Кент Бек утверждает, что тесты в ТДД это не юнит-тесты. Вот в этом весь фокус.
Для того, что бы писать тесты, нужно уже более менее знать, какая будет вычислительая модель и какие у ней свойства. Далее, основываясь на этих знаниях, можно писать тесты. Какая будет реализация самого компонента унутре, совершенно неважно.
В твоем случае это будет "если сработали датчики Q1 и Q14, не позже чем через 2 секунды должно быть отправлено сообщение F176, и повторяться каждые 1-3 секунд до изменения условия"
Ш>Суть её в следующем. Мы пишем некоторый софтварный компонент. Ш>Далее мы пишем тесты для него. Прогоняем. Ш>Большинство программистов на этой стадии останавливаются. Но останавливаться не надо.
Добавлю в копилку ко всему обсуждению. Есть такая малоизвестная штука под названием property-based testing. Настолько малоизвестная, что даже в википедии про нее ничего нет, кроме описания самого главного продукта для этого дела, QuickCheck'а [1][2] Эта штука, правда, тербует определенного ломания мозга, но она прикольная.
Общая идея такая:
— у нас есть спецификация того, что должен реализовывать код
— мы максимально декларативно описываем:
-- спецификацию
-- тип входных данных
-- условия, описывающие поведение кода
После этого генерится толпа входных данных и проверяются условия. В случае, если некий набор данных ломает тест, некоторые реализации (типа QuickCheck'а и PropEr'а) умеют сузить этот набор до минимального набора, гарантированно ломающего тест.
Что это дает?
1. Мы тестируем не реализацию, а спецификацию.
Чем это хорошо? Тем, что программисты чаще всего тестируют именно реализацию (которая может сильно отличаться от спецификации, потому что мы все люди-человеки, и часто смотрим в описание задачи, а видим фигу).
2. Мы генерируем множество входных данных
Чем это хорошо? Это позволяет в автоматическом режиме проверить вещи, которые при написании тестов вручную можно забыть (пограничные значения? проверка на ноль и отрицательные значения, когда проверяем функцию, работающую с числами? «магические» комбинации чисел? и т.п.)
Как это выглядит
Примерно так:
для всех X, Y, Z таких, что
X = целые числа,
Y = список различных комбинаций целых чисел
Z = пользовательский тип
проверить следующее условие:
вызов функции F(X, Y, Z) приводит к таким-то и таким-то результатам
Ну или например в Erlang'е (откуда есть пошел Quickcheck)[3]
?FORALL( {X, Y, Z}
, {int(), list(int()), custom_type()}
, F(X, Y, Z) =:= F(-X, Y, Z) %% зависит от того, что ваша функция будет делать
).
QuickCheck сгенерит рандомные[4] целые числа, рандомные списки рандомных чисел и рандомные custom_type'ы и будет проверять эти условия. По умолчанию 100 раз на разных наборах данных, но можно — сколько угодно раз (есть люди, которые оставляют QuickCheck на ночь — генерировать входные данные миллионами).
Если в реализации спецификации будет ошибка, она будет выявлена
А теперь — слайды! примеры!
В Erlang'е есть функция lists:seq, спецификация которой выглядит так:
lists:seq(From, To, Incr)
Генерит список чисел от From до To с шагом Incr. Для любых последовательностей справделиво следующее:
— length(lists:seq(From, To)) == To-From+1
— length(lists:seq(From, To, Incr)) == (To-From+Incr) div Incr
Функция вылетает с ошибкой если
— To < From-Incr, Incr > 0
— To > From-Incr, Incr < 0
— Incr == 0, From /= To.
... в этом месте обычно задается вопрос: какие тесты вы бы написали для проверки вручную ...
Давайте напишем тест:
Для всех From, To, Incr, где
From = int(),
To = int(),
Incr = int()
проверить следующее условие:
попытаться получить список из lists:seq(From, To, Incr)
если список получен, то length(Список) == (To-From+Incr) div Incr
если функция вылетела с ошибкой, то одно из следующих верно:
- To < From-Incr, Incr > 0
- To > From-Incr, Incr < 0
- Incr == 0, From /= To.
На Erlang'е:
prop_seq4() ->
?FORALL( {From, To, Incr}
, {int(), int(), int()}
, try
List = lists:seq(From, To, Incr),
length(List) == (To - From + Incr) div Incr
catch
error:_ ->
((To < From - Incr) andalso Incr > 0) orelse
((To > From - Incr) andalso Incr < 0) orelse
(From /= To andalso Incr == 0)
end
).
Давайте проверим:
> eqc:quickcheck(lists_eqc:prop_seq4()).
Failed! After 1 tests.
{0,0,0}
Опаньки. Если From == 0, To == 0, Inc == 0, то тест вылетает к чертям. То есть код у нас неправильно реализует спецификацию. Ладно, можно добавить одно условие в тест
На мелком примере это видно плохо, но property-based testing позволяет (при должном подходе) избегать необходимости вносить ошибки в код для проверки тестов. При условии, конечно, что спецификации заданы правильно и тесты проверяют то, что надо, а не что бог на душу положит
В Кларне при помощи QuickCheck'а нашли плохо воспризводимый баг в Мнезии (терялись данные при какой-то последовательности операций). QC нашел последовательность в 14 шагов, потом сузил ее до трех. Можно почитать про подобное и в LevelDB. Можно еще почитать Эрикссоновский отчет про тестирование протокола Megaco.
В общем, весьма рекомендую и советую к использованию.
[1] Quickcheck сильно коммерческий, но существует его упрощенная бесплатная версия, QuickCheck Mini
[2] Греческий парень по имени Kostis Sagonas, увидев Quickcheck, решил его реверс-инжинирнуть и создать бесплатную версию с таким же интерфейсом. Называется PropEr
[3] Да-да, он сначала был реализован на Хаскеле, но потом его переписали на Erlang'е, и уходить с Erlang'а авторы, вроде, не собираются
[4] Генерация не прямо рандомная, но выборка идет ближе к «левому» краю распределения данных. Поэтому иногда надо запускать много тестов (тысячу-две), чтобы покрыть все данные. Ну или использовать helper functions для изменения распределения данных.
Здравствуйте, Ikemefula, Вы писали:
N>>Прости, что непонятно в написанном выше?? Я даже квотинг привожу полностью. I>По моему функциональные тесты != юнит-тесты.
Функциональные тесты — это те, что проверяют собственно функциональность. То есть что при таких входных параметрах/условиях получаются такие выходные. Кроме них могут быть тесты производительности, защиты, побочных эффектов, и так далее.
Юнит-тесты это важный частный случай функциональных тестов — для отдельно взятой функции, метода, наконец, класса.
Здравствуйте, Ikemefula, Вы писали:
N>>1. Как я уже говорил, обычно TDD соотносится именно с юнит-тестами, то есть (в стандартных терминах) тестах конечных функций и методов. Теме соответствия спецификациям и порождённых из тех сценариев посвящён BDD. I>Сам Кент Бек утверждает, что тесты в ТДД это не юнит-тесты. Вот в этом весь фокус.
I>Для того, что бы писать тесты, нужно уже более менее знать, какая будет вычислительая модель и какие у ней свойства. Далее, основываясь на этих знаниях, можно писать тесты. Какая будет реализация самого компонента унутре, совершенно неважно.
Я даже готов поверить в это, несмотря на то, что "широкие народные массы" стали интерпретировать его заметно иначе. Но мне на самом деле всё это деление глубоко пофиг. Мне не пофиг другое — что я уже пару раз описывал в этом треде — что его метод в таком виде принципиально лажается на нескольких простых и очень вероятных ситуациях, как уточнение спецификации к уже существующему коду. А вот предложенная здесь методика затыкает эти дыры и решает вопрос с такими ситуациями, простым и эффективным способом.
I>В твоем случае это будет "если сработали датчики Q1 и Q14, не позже чем через 2 секунды должно быть отправлено сообщение F176, и повторяться каждые 1-3 секунд до изменения условия"
Ну так это сейчас и называется BDD: описывается условие спецификации и тест строится точно по ней. Вот после этого можно уже идти копаться во внутренностях. Но если ты среднему senior'у или PM'у расскажешь свою интерпретацию, боюсь, тебя не поймут...
Здравствуйте, netch80, Вы писали:
N>Я даже готов поверить в это, несмотря на то, что "широкие народные массы" стали интерпретировать его заметно иначе. Но мне на самом деле всё это деление глубоко пофиг. Мне не пофиг другое — что я уже пару раз описывал в этом треде — что его метод в таком виде принципиально лажается на нескольких простых и очень вероятных ситуациях, как уточнение спецификации к уже существующему коду. А вот предложенная здесь методика затыкает эти дыры и решает вопрос с такими ситуациями, простым и эффективным способом.
Да, лажается. В основном потому, что ТДД в массе рассматривают как "написание системы тестов"
N>Ну так это сейчас и называется BDD: описывается условие спецификации и тест строится точно по ней. Вот после этого можно уже идти копаться во внутренностях. Но если ты среднему senior'у или PM'у расскажешь свою интерпретацию, боюсь, тебя не поймут...
По моему средний сеньор или ПМ смотрит на ТДД именно как на написание системы тестов
Здравствуйте, netch80, Вы писали:
N>В варианте Шахтёра делается, считаем, чуть иначе — в станции выдёргивается датчик воды в накопителе. Но результат должен быть тем же — если она не сказала, что дождя нет, что-то происходит не так.
А почитай контекст. Ikemefula предложил использовать идею топикстартера для
Зато с помощью предложеного способа можно найти куски проекта, кторые как бы покрыты тестами, а на самом деле тесты или работают при нерабочем приложении, или отваливаются при рабочем приложении.
Именно к этому и относилось "шаманство". Зачем ловить фактически непокрытые тестом места дорогостоящим ручным тестированием, когда то же самое получается из test coverage report, что генерится практически любым юниттест-фреймворком?
И так с любыми другими способами оправдать применение методики "ломаем, смотрим что вышло": то же самое достигается стандартными приёмами, зачем тут изобретать велосипед —
Идея топикстартера в принципе не автоматизируется, не проверяется, не даёт предсказуемого соотношения затраты/результат. Следовательно, она не подходит для регулярного тестирования софта.
В частном порядке, для поиска проблемных мест или для разбирательства с поломатым тестом — сколько угодно. Другое дело, что:
1. К тестированию проекта это уже не имеет никакого отношения. Примерно с тем же успехом можно кидать дротики в распечатанный листинг и проверять все строчки, в которых есть дырка.
2. Для разборок с тестами тоже есть гораздо более эффективные и дешёвые методики (например, инварианты в CodeContracts),
ну да фиг с ним.
Остальное скипнул, походу мы по-разному смотрим на процесс тестирования.
N>Но в моей методике дефекты в основном вводятся не в код (хотя и это можно сделать — выставляя через тест-окружение команды "сломаться тут"), а в задания теста. Если тест типа "сделали 10 нажатий мышой в конкретных местах и проверили посылку файла", то инверсия — пропустить одно нажатие и убедиться, что файл не посылается. Необходимости делать такие точки пробной поломки именно в рабочем коде я пока не видел.
Сорри, когда отвечал выше, этого поста не увидел.
Вот такой подход — абсолютно правильная и логичная штука. Только эта идея (aka negative test) никакого отношения к предложенному топикстартером не имеет.
Здравствуйте, Sinix, Вы писали:
S>Именно к этому и относилось "шаманство". Зачем ловить фактически непокрытые тестом места дорогостоящим ручным тестированием, когда то же самое получается из test coverage report, что генерится практически любым юниттест-фреймворком?
Нужно всего то отделить говнотесты от нормальных. Твои методы сильно вряд ли работают. Я совсем недавно фиксил небольшую кучку тестов, которые периодически ломались. Случайно, закоментив лишнее, обнаружил, что тесты зеленые. Начал коментить все подряд и обнаружил, что тесты тестируют только моки, а поломки тестов происходили из а хитро-высушеного "реюзания", при чем совсем не в той части которая покрывалась тестами.
S>И так с любыми другими способами оправдать применение методики "ломаем, смотрим что вышло": то же самое достигается стандартными приёмами, зачем тут изобретать велосипед — S>Идея топикстартера в принципе не автоматизируется, не проверяется, не даёт предсказуемого соотношения затраты/результат. Следовательно, она не подходит для регулярного тестирования софта.
Правильно. Она и не предназначена для тестирования софта. Она предназначена для проверки самих тестов.
Здравствуйте, Ikemefula, Вы писали:
I>Нужно всего то отделить говнотесты от нормальных. Твои методы сильно вряд ли работают. Я совсем недавно фиксил небольшую кучку тестов, которые периодически ломались. Случайно, закоментив лишнее, обнаружил, что тесты зеленые. Начал коментить все подряд и обнаружил, что тесты тестируют только моки, а поломки тестов происходили из а хитро-высушеного "реюзания", при чем совсем не в той части которая покрывалась тестами.
Не-не-не, мы вроде не частные случаи обсуждаем, и не разбирательства с единичными тестами. Речь шла о обнаружении проблемных тестов на регулярной основе путём выборочной поломки кода.
Ключевое слово — регулярной. Единичные проверки дают информацию, которая очень быстро устареет. Насколько нам важно знать, что неделю назад с тестами всё было ок? Точнее не с тестами, а с парой-другой тестов, потому что поломать так, чтобы проверить всё — это тоже надо уметь.
Однотипные поломки тупо повторять не выйдет. Jazzer выше привёл пример, почему:
Ну будет у тебя в реализации какая-то особая точка, скажем, ты делишь на 3-x, и поэтому надо особо обрабатывать случай x=3. Ну, допустим, ты это заметил, даже тест написал. А потом пересчитал свою матмодель и поменял реализацию на 5-x — все твои существующие тесты замечательно это схавают, если в них случайно не будет проверки случая x=5 (а с чего бы). И что, выкинуть 3, добавить 5? или добавить тестирование всего натурального ряда, и заодно числа пи — мало ли как еще изменится реализация?
Топикстартер то же самое пишет:
Для того, что бы вскрыть ошибки в реализации, надо проанализировать код и писать тесты отталкиваясь от кода.
Т.е. ты серьёзно надеешься, что команда будет тратить по несколько часов в неделю на рутинную процедуру "перечитай код, перечитай тесты, вспомни интересные для проверки места и попробуй сломай код?".
Ну ок, вот разработчик потратил пару часов, сломал код, причём так, что без переписывания значительной части функционала ошибку не обойти (а такие узкие места by design есть практически в любом проекте). Ну, например, конкурентная вставка сообщений приводит к потере части сообщений.
После чего мы тратим ещё пару часов разработчика, тимлида и архитектора, чтобы прийти к выводу, что ошибка не проявится ни при каких обстоятельствах. Например, уровнем выше работает планировщик и тестировать неплохо бы как раз его.
Как будем документировать и доводить до сведения всей команды, что подобные места нет смысла проверять? Чем можно оправдать трату времени, если подобные ситуации возникают не в единичных случаях, а регулярно?
Это только один пример, я из практики могу ещё штук 5-6 причин привести, почему такой подход не подходит для регулярного использования. Только чур, давай не будем уходить в сторону "это плохой негодный проект, а правильные методики требуют идеальных проектов" и прочей сфероконине в стиле Бека.
S>>Идея топикстартера в принципе не автоматизируется, не проверяется, не даёт предсказуемого соотношения затраты/результат. Следовательно, она не подходит для регулярного тестирования софта. I>Правильно. Она и не предназначена для тестирования софта. Она предназначена для проверки самих тестов.
Тут без разницы что тестировать. Если методика не повторяема, то для тестирования она не подходит в принципе, выше уже объяснял почему. Хотя идея тестирования тестов мне кажется изначально порочной. Есть ассерты. Есть статистика срабатываний тестов. Есть negative tests (netch80 предложил выше
Здравствуйте, Sinix, Вы писали:
I>>Нужно всего то отделить говнотесты от нормальных. Твои методы сильно вряд ли работают. Я совсем недавно фиксил небольшую кучку тестов, которые периодически ломались. Случайно, закоментив лишнее, обнаружил, что тесты зеленые. Начал коментить все подряд и обнаружил, что тесты тестируют только моки, а поломки тестов происходили из а хитро-высушеного "реюзания", при чем совсем не в той части которая покрывалась тестами.
S>Не-не-не, мы вроде не частные случаи обсуждаем, и не разбирательства с единичными тестами. Речь шла о обнаружении проблемных тестов на регулярной основе путём выборочной поломки кода.
Правильно. Речь про обнаружение проблемных тестов, а не тестирование софта.
S>Ключевое слово — регулярной. Единичные проверки дают информацию, которая очень быстро устареет. Насколько нам важно знать, что неделю назад с тестами всё было ок? Точнее не с тестами, а с парой-другой тестов, потому что поломать так, чтобы проверить всё — это тоже надо уметь.
Ты код пишешь разово, регулярно или уже автоматизировал ?
Не надо ломать всё. Ломать нужно только то, с чем работаешь в данный момент. Если такой дизайн, что один тест сразу всё тестирует, то, конечно, тебе будет плохо.
S>Т.е. ты серьёзно надеешься, что команда будет тратить по несколько часов в неделю на рутинную процедуру "перечитай код, перечитай тесты, вспомни интересные для проверки места и попробуй сломай код?".
Я думаю, что если команда пишет тесты и пересматривает код, то нет никакой проблемы во время написания тестов проверять их методом поломки кода.
Сам подумай — для чего тебе тест ? Где гарантия что тест способен задетектить регрессию ?
S>Как будем документировать и доводить до сведения всей команды, что подобные места нет смысла проверять? Чем можно оправдать трату времени, если подобные ситуации возникают не в единичных случаях, а регулярно?
Я так понял, ты работаешь не иаче как в скопе приложения. Я вот так не умею. У меня в любой конкретный момент времени только один компонент, модуль и тд. Вот его тесты я и пробую проверять вот таким вот образом.
S>Это только один пример, я из практики могу ещё штук 5-6 причин привести, почему такой подход не подходит для регулярного использования. Только чур, давай не будем уходить в сторону "это плохой негодный проект, а правильные методики требуют идеальных проектов" и прочей сфероконине в стиле Бека.
У Бека нет разделение проектов на плохие и хорошие, и нет утверждения, что правильные методики требуют идеальных проектов. Более того, у него есть ровно противоположное — он утверждает, что его методики применимы и полезны во всех проектах. Ты хоть книгу его открой, а то мне кажется тебе сосед пересказал
I>>Правильно. Она и не предназначена для тестирования софта. Она предназначена для проверки самих тестов. S>Тут без разницы что тестировать. Если методика не повторяема, то для тестирования она не подходит в принципе, выше уже объяснял почему.
Она как раз повторяема.
>Хотя идея тестирования тестов мне кажется изначально порочной.
Если идея тестирования тестов не работает, то сами тесты так же не работают. Любой код может быть проверен. Если этого нет, этот код вообще не имеет никакого смысла, не важно, приложение это или тесты.
>Есть ассерты. Есть статистика срабатываний тестов. Есть negative tests (netch80 предложил выше
Здравствуйте, Шахтер, Вы писали:
Ш>Следующий шаг -- обратное тестирование. Мы берем исходный код и целенапрвленно вводим в него дефекты. И запускаем тесты. Ш>Если тесты не улавливают наличие дефектов, то тест-систему корректируем.
Для многих задач это невыполнимо. Например, контекстно свободный язык может предполагать бесскобочное множество выражений. Целенаправленное придумывание дефектов выльется в море практически бесполезных тестов. В этом случае имеет смысл покрыть тестами спецификацию языка и проверить корректность выдачи сообщений об ошибках. Ну, а далее по 1-2 теста на баг/фичу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Шахтер, Вы писали:
Ш>Вопрос в другом -- в достаточности множества тестов.
Было уже много работ по этому поводу. Все сходились на том, что:
1. Тестами в принципе нельзя гарантировать правильную работоспособность.
2. Невозможно вычислить достаточное количество тестов, так как п.
Итого достаточности количество тестов определяется на глаз.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Просто есть сходство.
Сорри, но на работе ты тоже на вопрос о рисках, которые ты пытаешься решить отвечаешь "сроки-бюджет"??? 
А почему? А потому, что если у тебя уже есть правильный код, а спецификация поменялась, тебе приходится или плевать на принципы TDD и заводить тест к уже работающему коду, или явно ломать код, чтобы убедиться, что тест его проверяет (то, что как раз описал Шахтёр). Например, тебе добавили в спеку "должно работать с числами до миллиарда". Ты задумчиво лезешь в код, видишь везде int64_t и начинаешь гадать, что сделать: отрапортовать, что всё и так работает? переписать весь код на short, чтобы поломалось, затем обратно, чтобы починить?
