Здравствуйте, ·, Вы писали:
·>Здравствуйте, mrTwister, Вы писали:
T>>·>Не очень понятно что конкретно ты хочешь обнаружить. Отпрпавка/получение это транспорт, и частью API как правило не является. T>>Ну вот мне было выше обещано, что с помощью юнит-тестов можно быстро обнаруживать слом публичного API внешней системы. Я пытаюсь понять, как именно это сделать. ·>"внешней системы"? Этого вроде не было. Внешняя система тестируется conformance-тестами и к твоему коду отношения не имеет.
Мой код может непавильно этот API использовать.
·>Не очень понятно, зачем тестировать и быстро обнаруживать ошибки в том как web-сервер обрабатывает http-запросы. Этим должны заниматься разработчики веб-сервера. Ну я понимаю, что должен быть небольшой end-to-end интеграционный тест, который проверяет, что твоё приложение правильно запускается, открывает нужные порты, и отвечает на какой-нибудь простой запрос.
Под веб-сервером имелся ввиду сервис, предоставляющий REST API.
Здравствуйте, mrTwister, Вы писали:
L>>Например, отрефакторил ты модуль в целях оптимизации. Заменил std::map на std::unordered_map. L>>Функциональность не изменилась, но записи в ответе на запрос больше не упорядочены по алфавиту. T>Ок, то есть речь идет о тестировании публичного API библиотеки. Но если тест тестирует целую библиотеку через её публичный API, то это не юнит-тест, а интеграционный.
Нет, это юнит тест. Который проверяет поведение одного из юнитов изолированного обработчика вызовов глубоко внутри библиотеки.
Здравствуйте, landerhigh, Вы писали:
L>Нет, это юнит тест. Который проверяет поведение одного из юнитов изолированного обработчика вызовов глубоко внутри библиотеки.
Тогда при чем тут публичный API библиотеки? Да, юнит-тест может найти баг в кишках, который может проявиться в некорректной работе публичного API, но юнит-тесты фокусируются не на этом, они ни про какой публичный API не знают и не тестируют его. При этом я не говорю, что юнит-тесты не нужны. Это инструмент, который имеет свою область применимости и свои ограничения, которые надо хорошо понимать. Не надо наделять его чудодейственными свойствами.
L>>Нет, это юнит тест. Который проверяет поведение одного из юнитов изолированного обработчика вызовов глубоко внутри библиотеки. T>Тогда при чем тут публичный API библиотеки? Да, юнит-тест может найти баг в кишках, который может проявиться в некорректной работе публичного API,
Вот причем:
Только интеграционные проблемы юнит-тестами не обнаруживаются, для этого интеграционные тесты нужны
Теперь оказывается, что не только не обнаруживаются, но и все же обнаруживаются.
L>Только интеграционные проблемы юнит-тестами не обнаруживаются, для этого интеграционные тесты нужны
L>Теперь оказывается, что не только не обнаруживаются, но и все же обнаруживаются.
Только это не интеграциюнная ошибка, это обычный алгоритмический баг. Интеграционная ошибка — это когда две системы непраильно взаимодействуют друг с другом, то есть ошибка на стыке систем.
Здравствуйте, mrTwister, Вы писали:
T>Только это не интеграциюнная ошибка, это обычный алгоритмический баг. Интеграционная ошибка — это когда две системы непраильно взаимодействуют друг с другом, то есть ошибка на стыке систем.
Нет никакого алгоритмического бага. Данные возвращаются, как и прежде.
Сломалась именно интеграция. Интеграционные тесты, кстати, эту особенность не уловили.
Здравствуйте, landerhigh, Вы писали:
L>Сломалась именно интеграция. Интеграционные тесты, кстати, эту особенность не уловили.
Данные возвращаются в неправильном порядке. Это была бы интеграционная ошибка, если бы упорядоченность никто и не обещал, а другая система необоснованно на неё завязалась. Если же модуль просто не выполняет свой контракт, то это не интеграционная ошибка.
Здравствуйте, mrTwister, Вы писали:
L>>Сломалась именно интеграция. Интеграционные тесты, кстати, эту особенность не уловили.
T>Данные возвращаются в неправильном порядке. Это была бы интеграционная ошибка, если бы упорядоченность никто и не обещал, а другая система необоснованно на неё завязалась. Если же модуль просто не выполняет свой контракт, то это не интеграционная ошибка.
Это ты клиентам попробуй объяснить.
В системах со сложными спецификациями всегда возникают ситуации, когда в спецификации есть пробелы, неявности или просто места, которые можно понять двояко. За примерами далеко ходить не надо
Результат подобной "не интеграционной ошибки" в одном конкретном случае выразился в мощном глобальном outage, куче убытков и потраченных сотнях человеко-месяцев на срочное исправление.
А копеечный юнит-тест эту ошибку не выпустил бы за пределы IDE разработчика.
Здравствуйте, landerhigh, Вы писали:
L>В системах со сложными спецификациями всегда возникают ситуации, когда в спецификации есть пробелы, неявности или просто места, которые можно понять двояко. За примерами далеко ходить не надо
.
Совершенно верно, и юнит-тесты эти места, которые можно понять двояко, не отловят. Есть спецификация. Команда "А" поняла её одним образом, написала код и юнит-тесты к этому коду в соответствии со своим пониманием. А команда "Б" поняла спецификацию по-своему, и тоже написала код и юнит-тесты согласно своему пониманию. У всех юнит-тесты успешно проходят, но совместно модули "А" и "Б" не работают, потому что спецификация была понята по-разному.
L>Результат подобной "не интеграционной ошибки" в одном конкретном случае выразился в мощном глобальном outage, куче убытков и потраченных сотнях человеко-месяцев на срочное исправление. L>А копеечный юнит-тест эту ошибку не выпустил бы за пределы IDE разработчика.
Я же не говорю, что юнит-тесты не нужны. Это инструмент, который иногда имеет смысл использовать для отлова алгоритмических ошибок. Но то, что спецификация была понята неправильно он не поймает.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, landerhigh, Вы писали:
L>>В системах со сложными спецификациями всегда возникают ситуации, когда в спецификации есть пробелы, неявности или просто места, которые можно понять двояко. За примерами далеко ходить не надо
. T>Совершенно верно, и юнит-тесты эти места, которые можно понять двояко, не отловят.
Отловят.
Вот из примера выше — замена std::map на std::unordered_map сломала юнит-тест.
Кодер класса "юнит-тесты не нужны" закоментил его.
Но его TL эту фишку просек, PR заблокировал и позвонил продакт овнеру.
А тот сказал, что раз в спецификации не оговаривается порядок сортировки данных, а значит, кто-то из клиентов поломается и виноваты будем мы.
L>>Результат подобной "не интеграционной ошибки" в одном конкретном случае выразился в мощном глобальном outage, куче убытков и потраченных сотнях человеко-месяцев на срочное исправление. L>>А копеечный юнит-тест эту ошибку не выпустил бы за пределы IDE разработчика. T>Я же не говорю, что юнит-тесты не нужны. Это инструмент, который иногда имеет смысл использовать для отлова алгоритмических ошибок. Но то, что спецификация была понята неправильно он не поймает.
При правильном применении они выявляют места, где спецификация может быть понята неправильно.
Здравствуйте, landerhigh, Вы писали:
L>Отловят. L>Вот из примера выше — замена std::map на std::unordered_map сломала юнит-тест. L>Кодер класса "юнит-тесты не нужны" закоментил его. L>Но его TL эту фишку просек, PR заблокировал и позвонил продакт овнеру. L>А тот сказал, что раз в спецификации не оговаривается порядок сортировки данных, а значит, кто-то из клиентов поломается и виноваты будем мы.
Ну то есть фактически вы внесли в контракт модуля порядок сортировки. Таким образом, был нарушен контракт модуля. Если модуль не выполняет свой контракт, это не интеграционный баг, а внутренний алгоритмический баг.
Здравствуйте, mrTwister, Вы писали:
L>>А тот сказал, что раз в спецификации не оговаривается порядок сортировки данных, а значит, кто-то из клиентов поломается и виноваты будем мы. T>Ну то есть фактически вы внесли в контракт модуля порядок сортировки. Таким образом, был нарушен контракт модуля. Если модуль не выполняет свой контракт, это не интеграционный баг, а внутренний алгоритмический баг.
Это уже словоблудие.
Еще раз — подобные баги есть во всех мало-мальски сложных спецификациях. Один из примеров — IEC61850 tissues.
Конченому пользователю, у которого из розетки вместо 220 полилось 380, насрать, интеграционный, алгоритмический это баг или просто звезды так сложились.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, mrTwister, Вы писали:
L>>>А тот сказал, что раз в спецификации не оговаривается порядок сортировки данных, а значит, кто-то из клиентов поломается и виноваты будем мы. T>>Ну то есть фактически вы внесли в контракт модуля порядок сортировки. Таким образом, был нарушен контракт модуля. Если модуль не выполняет свой контракт, это не интеграционный баг, а внутренний алгоритмический баг.
L>Это уже словоблудие.
Ну дак заканчивай его
L>Еще раз — подобные баги есть во всех мало-мальски сложных спецификациях. Один из примеров — IEC61850 tissues.
И? При чем тут это? Еще раз: если проблема в том, что нарушен контракт модуля, то это не интеграционные баг, независимо от того, явный ли контракт модуля, или нет.
L>Конченому пользователю, у которого из розетки вместо 220 полилось 380, насрать, интеграционный, алгоритмический это баг или просто звезды так сложились.
Речь про то, что для всего есть свой инструмент. Из того, что ты гвоздь назвал шурупом и забил его молотком никак не следует, что шурупы можно забивать молотками.
Здравствуйте, mrTwister, Вы писали:
T>>>Ну то есть фактически вы внесли в контракт модуля порядок сортировки. Таким образом, был нарушен контракт модуля. Если модуль не выполняет свой контракт, это не интеграционный баг, а внутренний алгоритмический баг.
Этот контракт нигде не был явно описан. Проблема именно интеграционная.
L>>Еще раз — подобные баги есть во всех мало-мальски сложных спецификациях. Один из примеров — IEC61850 tissues. T>И? При чем тут это? Еще раз: если проблема в том, что нарушен контракт модуля, то это не интеграционные баг, независимо от того, явный ли контракт модуля, или нет.
Это и есть словоблудие.
L>>Конченому пользователю, у которого из розетки вместо 220 полилось 380, насрать, интеграционный, алгоритмический это баг или просто звезды так сложились. T>Речь про то, что для всего есть свой инструмент. Из того, что ты гвоздь назвал шурупом и забил его молотком никак не следует, что шурупы можно забивать молотками.
С доказательствами по аналогии можно и впросак попасть. Некоторые види крепежа на основе шурупов или винтов по инструкции производителя перед завинчиванием забиваются молотками.
Можно сколько угодно упражняться в словоблудии, но если копеечный юнит-тест позволяет обнаружить, выявить или хотя бы предсказать заслуживающую дальнейшего расследования проблему интеграционного уровня, то написание этого юнит-теста оправдано.
Здравствуйте, landerhigh, Вы писали:
L>Этот контракт нигде не был явно описан. Проблема именно интеграционная.
Но при этом контракт подразумевался, как минимум, в голове у TL. Либо библиотека должна возвращать элементы в отсортированном виде, либо не должна. Если должна, то неважно почему: потому что так написано в спецификации, или потому что уже есть клиенты, которые на это завязались. И в том и в другом случае это контракт библиотеки. Причем во втором случае надо еще отредактировать спецификацию и зафиксировать в ней требование по сортировки, чтобы оно было явное, раз уж оно все равно есть и его надо поддерживать.
L>Это и есть словоблудие.
Словоблудие — это называть интеграционным багом обычное нарушение контракта, которое можно ловить юнит-тестами и делать из этого вывод, что юнит-тесты подходят для поиска интеграционных ошибок.
L>С доказательствами по аналогии можно и впросак попасть. Некоторые види крепежа на основе шурупов или винтов по инструкции производителя перед завинчиванием забиваются молотками.
К чему ты это написал? Спор ради спора?
L>Можно сколько угодно упражняться в словоблудии, но если копеечный юнит-тест позволяет обнаружить, выявить или хотя бы предсказать заслуживающую дальнейшего расследования проблему интеграционного уровня, то написание этого юнит-теста оправдано.
Я с этим и не спорю. Действительно, гвоздь удобно забивать молотком. Я спорю с тем, что надо шурупы молотком забивать.
Здравствуйте, mrTwister, Вы писали:
L>>Этот контракт нигде не был явно описан. Проблема именно интеграционная. T>Но при этом контракт подразумевался, как минимум, в голове у TL. Либо библиотека должна возвращать элементы в отсортированном виде, либо не должна.
Он нигде не подразумевался и нигде не был описан.
Он сформировался постфактум и неявно, когда клиенты наблюдаемое поведение посчитале зафиксированным в контракте. Клиент, конечно, не прав в том, что полагался на поведение, никем не гарантированное, но удачи объяснить ему, что ему нужно теперь перепрошить ПЗУ в 100500 девайсах по всему миру.
T>Если должна, то неважно почему: потому что так написано в спецификации, или потому что уже есть клиенты, которые на это завязались. И в том и в другом случае это контракт библиотеки. Причем во втором случае надо еще отредактировать спецификацию и зафиксировать в ней требование по сортировки, чтобы оно было явное, раз уж оно все равно есть и его надо поддерживать.
Твоими устами бы да медку хлебнуть.
Ошибки в спецификациях неизбежны.
Я уже привел несколько примеров. Тот же МЭК 61850 специально обученные люди больше 10 лет разрабатывали, но тем не менее, мест, которые исходя из разработанной ими спецификации, можно было понять двояко, там осталось овердофига. В результате имеем зоопарк из девайсов, реализуемых определенные ключевые API разным путем.
Редактируй, фиксируй, какие проблемы?
Ах да, эти девайсы уже внедрены и их перепрошивка в общем случае невозможна.
L>>Можно сколько угодно упражняться в словоблудии, но если копеечный юнит-тест позволяет обнаружить, выявить или хотя бы предсказать заслуживающую дальнейшего расследования проблему интеграционного уровня, то написание этого юнит-теста оправдано.
T>Я с этим и не спорю. Действительно, гвоздь удобно забивать молотком. Я спорю с тем, что надо шурупы молотком забивать.
Ну то есть, если юнит-тест вдруг выявил проблему интеграционного уровня, то это забитый молотком шуруп?
Здравствуйте, Тёмчик, Вы писали:
Тё>Тест всегда проходит, похрен что "тестируемая" функция совсем иначе себя ведёт. И вот этому тесту был посвещен целый тикет в жыре.
Есть такие штуки для тестирования тестов как Weak Test (проверяет есть ли ассершны вообще) и Mutation Test (aka StringTest) (проверяет работают ли ассершны) https://pitest.org/
Я когда то писал и то и другое, первый несмотря на свою наивность находит кучу говна, второй подход муторный и сложный но твой кейс наверняка поймает.
Здравствуйте, gandjustas, Вы писали:
G>Интеграционные, функциональные тесты. Design by contract, типизация, статичские верификаторы. G>По моему опыту статическая ферификация на предмет самых популярных ошибок дает самый лучший результат.
Это да. Но как обосновать заказчику необходимость в команде в 100 человек, ибо если ограничиться интеграционными и функциональными проект вполне можно сделать тремя разработчиками, пятью начальниками и аналитиками и пятью тестировщиками ? Когда юнит тесты с полным покрытием — все заняты, пишут тесты, движуха неимоверная, и даже такого количества людей не хватает.
? Когда юнит тесты с полным покрытием — все заняты, пишут тесты, движуха неимоверная, и даже такого количества людей не хватает.
