Здравствуйте, 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. Невозможно вычислить достаточное количество тестов, так как п.
Итого достаточности количество тестов определяется на глаз.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
