[истории успеха] Разработка через тестирование

> у реального продукта бесконечное множество вариантов использования

это ещё доказать надо

Легко. Берем к примеру телефонную книгу. Типичное требование к ней - бесконечное количество записей с любыми комбинациями букв в имени и знаков цифр, плюс, минус, пробел в номере.

Докажи, что это множество конечно. ;)

Если ты хочешь верифицировать код тестами, тебе придется сначала верифицировать сами тесты.

Вообще я подумал, строго говоря, это вообще не так. Задача верификации не решает задачу верификации самих спецификациях. Хотя я слышал о неких спецификациях на спецификациях.

Прогонка тестов с задачей верификации справляется. Вопрос верификации тестов - совершенно отдельная тема.

Я отказался от них именно по тому, что ни разу за несколько месяцев использования они не сказли мне о моём коде больше того, что я о нём уже знал.

тесты и не должны тебе говорить о коде :)

ещё раз прошу: расскажи как ты пишешь код

Сказку, что по тестам можно понять контракт кода я тоже проверил на коде коллег - нельзя.

ты ж говоришь, что они пишут говнотесты, да с говнотестами всё только запутывается, и что это показывает? правильно! писать говнотесты - контрпродуктивно

Запили историю успеха, покажи как тесты изменили твою жизнь.

не надо сарказма

> я Вам привёл пример когда Вы пишете код с использванием тестирвоания сейчас, но нет ещё нижележащего/вышележащего кода - Ваш аргумент ушёл со свистом по трубе, смытый набежавшей водой

Ваша правда. С такой наркоманией, как кодирование без существующего нижележащего кода я еще не встречался. Только вам не кажется, что написание тестовых заглушек нижележащего кода - это уже как бы имплементация этого самого кода? И, кстати, нет никакой гарантии, что эта имплементация будет соответствовать той, которой нужно. ;)

Сказку, что по тестам можно понять контракт кода я тоже проверил на коде коллег - нельзя.

С таким явлением тоже встречался. Не всегда тесты можно написать хорошими. В крайнем случае это будет тест на регрессию.

А где шла речь о «модулях»? Я этого не вижу, пруфы, пожалуйста.

вижу, что не видите, но заголовок «Разработка через тестирование» неиллюзорно намекает на использование TDD, которое, в свою очередь, оперирует модульными тестами (unit tests)

> Это формальная верификация. Просто более строгая.

Нет никакой «неформальной» верификации. И нет никакого «более» или «менее» строгого.

Тесты - это облегченная ее версия.

Тогда «чтение ауры» - «облегченная версия» медицинского диагноза.

> простите, а Вы как пишете код, не поделитесь?

«По старинке» - формулирование требований, декомпозиция задачи и так далее. Ничего революционно нового. Я ретроград.

не, понятно, а пишете то как? в смысле как проверяете что код работает

>> А с какой целью интересуетесь?

хочу понять Вашу точку зрения

Я уже изложил её: [истории успеха] Разработка через тестирование (комментарий)

это не точка зрения, уж простите, это исповедь обиженного человека

Мой риторический вопрос имеет смысл только в том контексте.

Вы не задавали вопроса, я Вам задал вопрос, если что

К примеру, тривиальная «спека» - «возможность добавить в базу данных 'большое' количество записей о клиентах». Никак не получается заменить на тесты. Ну никак.

Действительно тривиальная спека, реализуемая нагрузочным тестом.

Докозательство - это формальная процедура.

Ну тут опять же все дело в качестве самих тестов. Можно загнаться и написать прям совсем формальные спеки. Правда трудоемкость коллосально возрастает.

И да, я делаю её для сложных участков кода.

А как вы то делаете? И как гарантируете, что это доказательство будет совершаться при элементарном рефакторинге? Если вы пишите на SPARK-е, то я снимаю шляпу. Хотя его спеки те же тесты, только формальные.

> у реального продукта бесконечное множество вариантов использования

это ещё доказать надо

Легко. Берем к примеру телефонную книгу. Типичное требование к ней - бесконечное количество записей с любыми комбинациями букв в имени и знаков цифр, плюс, минус, пробел в номере.

Докажи, что это множество конечно. ;)

1.вариантов использования у телефонной книги не то чтобы много, и это, уж точно, не зависит от количества номеров в ней
2. требование бесконечного количества записей - суть идиотизм, ибо для его реализации потребуется бесконечное количество памяти

Только вам не кажется, что написание тестовых заглушек нижележащего кода - это уже как бы имплементация этого самого кода?

нет, это только, в определённом смысле, проектирование ожидаемого поведения этого кода, и это суть любого mocking framework

И, кстати, нет никакой гарантии, что эта имплементация будет соответствовать той, которой нужно. ;)

конечно нет, скажу по серету - тесты вообще ничего не гарантируют, они лишь позволяют держать определённые вещи под контролем, думать о тестах как о волшебном средстве от всех ошибок - это ошибка

> Берем к примеру телефонную книгу.

Докажи, что это множество конечно. ;)

Это как раз нетрудно. Множество телефонов конечно, множество людей - тоже. Так что и множество комбинаций конечно.

Не всегда тесты можно написать хорошими.

что Вы имеете в виду?

> не перекладывать, а использовать как подстраховку

Подстраховку от чего? Чего бояться-то?

тесты не «показывают» ошибки, они позволяют их не допускать, серьёзно

Ну так я тебя и прошу - покажи КАК.

а ещё тесты дают определённую уверенность в том что написанный код работает как надо, даже после рефакторинга

Не дают, т.к. рефакторинг - это изменение API и, следовательно, изменение целой пачки тестов, его тестирующих. Это, кстати, было, пожалуй, основной причиной, по которой лично я от них отказался. Они реально мешают разработке.

> Докозательство - это формальная процедура. И да, я делаю её для сложных участков кода. Вместо написания тестов.

А тест, который проверяет, что доказательство всё еще в силе, не пишешь?

> Множество телефонов конечно,

Не телефонов, а телефонных номеров. Сам посмотришь, сколько новых номеров вводят в работу каждый день?

множество людей - тоже.

Количество рождающихся на планете ежедневно тоже посмотришь сам. ;)

И нет никакого «более» или «менее» строгого.

Есть :) Мир не черно белый.

> Прогонка тестов с задачей верификации справляется.

Я уже дважды сказал, что это не верификация. Не надо переопределять этот термин.

> не перекладывать, а использовать как подстраховку

Подстраховку от чего?

от появления различного рода ошибок, и сразу скажу - это не означает никакой «гарантии», просто вероятность появления ошибки снижается

Чего бояться-то?

появления ошибок, которые можно не заметить, работая над другими участками кода

рефакторинг - это изменение API

это не так

Рефакторинг (англ. refactoring) — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы.

>>И нет никакого «более» или «менее» строгого.

Есть :) Мир не черно белый.

Я прекрасно это знаю, у меня у самого - труколор. По октету на цвет и еще один на альфа-канал. ;)

Мир компьютерной логики пока описывается булевой алгеброй, которая как известно двоична. И видимо еще долго будет, пока не введут в эксплуатацию квантовые компьютеры.

что Вы имеете в виду?

Я убежден, что behavioral-тесты по определению хреновые. Но лучше хотя какой-то тест, чем никакой.

> тесты не «показывают» ошибки, они позволяют их не допускать, серьёзно

Ну так я тебя и прошу - покажи КАК.

это, несмотря на внешеюю простоту концепции, не так просто сделать и вживую, здесь это зделать на порядок труднее

вот здесь есть неплохое введение, только прошу Вас не плюйтесь сразу, прочитайте внимательно

>> А где шла речь о «модулях»? Я этого не вижу, пруфы, пожалуйста.

вижу, что не видите, но заголовок «Разработка через тестирование» неиллюзорно намекает

На то, что наш разговор в этот момент не имел к заголовку никакого отношения. Мы вообще-то о верификации программ говорили. Так что как вам удалость сделать вывод, что я путаю модульное тестирование с приёмочным - остаётся для меня загадкой.

>что Вы имеете в виду?

Я убежден, что behavioral-тесты по определению хреновые.

почему же, есть целая концепция BDD, вроде довольно таки стройная и интересная

Но лучше хотя какой-то тест, чем никакой.

к сожалению - не всегда, иногда, коряво написанные тесты, довольно сильно мешают

На то, что наш разговор в этот момент не имел к заголовку никакого отношения.

чёрт, всё время забываю что нахожусь на ЛОРе :)

>> Докозательство - это формальная процедура. И да, я делаю её для сложных участков кода. Вместо написания тестов.

А тест, который проверяет, что доказательство всё еще в силе, не пишешь?

Нет, количество инвариантов в реальном коде очень велико. Большая часть инвариантов касается поведения внешнего мира - вывзовы ос/данные ввода и т.п. Проверять все - я повешусь. Проверять несколько основных - профанация.

Вот, скажем, парсинг конфига. Если я добавлю новую ветвь в конфиг, я могу легко отследить работающий с ним код, доработать его и проверить на инварианты. При одной мысли об объёмах правки тестов на ВСЕ инваринаты входных данных, которые бы пришлось сделать, мне становиться не по себе.

Мир компьютерной логики пока описывается булевой алгеброй, которая как известно двоична. И видимо еще долго будет, пока не введут в эксплуатацию квантовые компьютеры.

Вот не надо передергивать. Вы уже совсем не в ту степь.

Приведу пример: есть стакан, емкость его 200 мл. Он заполнен на 199 мл. Строго говоря, он не заполнен полностью, то есть он не полон. Но из этого никак не следует, что он пустой. По вашей логике, он пуст, так как не формальность тестов означает их ненужность.

И вообще это опять же все не от том. Формальная верификация - это проверка формальных спецификаций. Просто такая терминология. Есть более общее понятие - верификация: проверка чего-то на соответствие спецификации. Прогонка тестов отлично с этой задачей справляется. Сделайте спецификации («тесты») формальными, будет вам формальная верификация.

> Нет, количество инвариантов в реальном коде очень велико

Проверять все - я повешусь.

Проблема в дизайне.

>> Подстраховку от чего?

от появления различного рода ошибок, и сразу скажу - это не означает никакой «гарантии», просто вероятность появления ошибки снижается

Лично у меня ошибок в кодах тестов было больше, чем в тестируемом коде. Это, разумеется, исключительно моя вина, но писать упятеренные/удесятерённые объёмы кода (а это нижняя шкала, если реально тестировать каждую функцию) ради сомнительного уменьшения вероятности - увольте.

Я ведь вовсе не говорю, что ТДД не работает. Работает, наверно... Весь вопрос в эффективности.

почему же, есть целая концепция BDD, вроде довольно таки стройная и интересная

Не, это не то. Вот что забавно, BDD совершенно ортогонально типу теста: behaviroal/state-based.

>> рефакторинг - это изменение API

это не так

Рефакторинг (англ. refactoring) — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы.

Это так. Лично я понимаю под рефакторингом изменение контрактов используемого кода. Все знакоме мне коллеги - тоже. На внешнем поведении программы это изменение, естественно, не должно сказаться. Т.о. моё (и моих коллег) понимание рефакторинга соответствует определнию.

И самое главное - это не ответ на вопрос, чё делать с кодом тестов при изменении контрактов используемого в программе кода.

При одной мысли об объёмах правки тестов на ВСЕ инваринаты входных данных, которые бы пришлось сделать, мне становиться не по себе.

А мне так не кажется. Я бы один метод в тестах поменял, тот который инвариант проверяет.

чё делать с кодом тестов при изменении контрактов используемого в программе кода.

Если говорить о каком-то сферическом случае из вакуума, то у тестов тоже должная быть своя затейливая архитектура.

Но у меня все как-то достаточно просто получается, ни разу не приходилось сильно ворошить тесты.

> Вот не надо передергивать.

Это кто еще передергивает..

Вы уже совсем не в ту степь.

Именно в ту. Верификация кода - это чёткий однозначный термин, хорошо известный в литературе и не надо его переопределять в своём узком кругу.

>>> Нет, количество инвариантов в реальном коде очень велико

Проверять все - я повешусь.

Проблема в дизайне.

Ну ёпт, еще один мыслитель века. Расскажешь, как свести работу чего-нибудь простенького, типа ls, к десятку инвариантов?

«Verification: The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. [IEEE-STD-610].»

Прогонка тестов - это верификация. Тютелька в тютельку.

> Я бы один метод в тестах поменял, тот который инвариант проверяет.

Правильно! Осталось только понять, что при нормальном тестировании проверяться должны ВСЕ инварианты. Проверка только трех с половиной - это профанация.

что при нормальном тестировании проверяться должны ВСЕ инварианты.

Это вы уже хотите формальную верификацию. Хотите - делайте. Берите SPARK и вперед. Еще раз: из неформальности метода не следует его ненужность. Пример со стаканом я уже приводил.

> Verification: The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. [IEEE-STD-610]."

Прогонка тестов - это верификация. Тютелька в тютельку.

Где ты тут слово «тест» увидел? Ну что ж мне за тебя-то приходится на википедию ходить?

http://ru.wikipedia.org/wiki/Формальная_верификация

Тестирование программного обеспечения не может доказать, что система, алгоритм или программа не содержит никаких ошибок и дефектов и удовлетворяет определённому свойству. Это может сделать формальная верификация.

Стыд тебе и позор!

> Еще раз: из неформальности метода не следует его ненужность.

А где я говорил о «ненужности»? Пруфы есть?

> Осталось только понять, что при нормальном тестировании проверяться должны ВСЕ инварианты. Проверка только трех с половиной - это профанация.

По сравнению с ручным «доказательством» - не так уж плохо.

Где ты тут слово «тест» увидел?

А должен?

http://ru.wikipedia.org/wiki/Формальная_верификация

Да хватит путать верификацию с ее частным случаем - формальной верификацией.

Тестирование программного обеспечения не может доказать, что система, алгоритм или программа не содержит никаких ошибок и дефектов и удовлетворяет определённому свойству. Это может сделать формальная верификация.

Бредятина. Во-первых «не содержит никаких ошибок» и «удовлетворяет определённому свойству» вещи мягко говоря разные. Первое не может обеспечить и формальное верификация. Второе («удовлетворяет определённому свойству») может быть обеспечено и тестом.

И вообще не читайте русской википедии :)

> вот здесь есть неплохое введение,

Шутить изволите? Я читал ISBN 0-13-148239-4 и ISBN 1-932394-85-0, не говоря уже о тоннах вот таких вот «факториалов» в интернетах. Еще раз напомню, речь не о том, что «это не работает», речь об эффективности трудозатрат.

несмотря на внешеюю простоту концепции, не так просто сделать и вживую, здесь это зделать на порядок труднее

У меня сделать в живую не получилось. Не в смысле написания тестов, а в смысле трудозатрат на поддержку и синхронизацию тестов с самим продуктом, так что я пока что предпочитаю code review.

А где я говорил о «ненужности»? Пруфы есть?

«Если тесты не служат проверкой корректности приложения, то зачем они нужны? Вселять в программиста слепую веру, что „всё правильно“?»

И там ты имел ввиду формальную корректность.

>> Осталось только понять, что при нормальном тестировании проверяться должны ВСЕ инварианты. Проверка только трех с половиной - это профанация.

По сравнению с ручным «доказательством» - не так уж плохо.

Ты, видимо, что-то путаешь. Речь-то идёт не о тестировании, а о TDD.

> И там ты имел ввиду формальную корректность.

Ну разумеется. Слава богу, что хоть кто-то меня понимает..

> Ты, видимо, что-то путаешь. Речь-то идёт не о тестировании, а о TDD.

А, уже снова о TDD? Трудно понять, о чем говоришь в данный конкретный момент.