Здравствуйте, Ватакуси, Вы писали:
В>Mock everything В>Call something В>Check something called something 1, something 2, etc.
В>Результаты работы вообще никак не проверяются.
Карго-культ.
Скорее всего, среди лидов или менеджеров.
Ну и подход к разработке среди девелоперов "некогда ерундой заниматься, нужно копать".
Здравствуйте, Ikemefula, Вы писали:
I> не существует методики ни разработки, ни тестирования, которая может дать гарантию отсутствия ошибок
Ну почему же. Формальная верификация даёт такую гарантию — где она применима.
А область её применимости таки постепенно расширяется.
Другой вопрос, что потом это всё вернётся на физический уровень с забагованными процессорами
I>Точно так же и в security не сущетсвует способа дать гарантию отсутствия любых уязвимостей.
Есть — полная физическая изоляция
I>Собственно, это не повод отказываться от тестирования, т.к. именно здесь мы убеждаемся, что
Ничего не повод отказываться от тестирования, потому что всегда есть шанс что-то пропустить уже в тех постулатах, на которых основывается конкретная верификация.
И вот это тут важнее.
I>1. методы а и б работают на предложенном множестве данных. I>2. компоненты обладают нужным поведением I>3. модуль, пакет предоставляют нужные функциональные возможности I>4. приложение умеет нужные функции, см перечень I>5. приложение покрывает все известные сценарии, см перечень сценариев I>6. приложение покрывает все критические кейсы, см перечень кейсов
И обычно последние два пункта доводят требования до состояния полной нереализуемости.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, varenikAA, Вы писали:
AA>>Это очевидно, сначала нужен тестируемый объект.
N>Вообще-то исследовательские разработки ведутся как раз наоборот: сначала тесты, а потом код. Точнее, сначала описывают требования, потом под них пишут тесты, а уже потом начинают разработку.
Полно исследовательских проектов, которые что-то родили совсем не то, что предполагалось изначально.
См. например историю транзистора.
[...] N>7. Начинаем писать код? Да, ведь у нас уже есть всё, для тестирования результата. Сочиняем архитектуру нейросети, обучаем и следим за тем, как она по подготовленным данным обучается. N>8. Обучили. Пишем код для того, чтобы отправить обученную нейросеть в продакшен на телефончик.
N>Любая другая последовательность действий изначально обречена на провал. Надо сначала собрать данные, на которых будет работать программа. Надо описать программно сценарии работы и критерии правильности и только потом есть смысл что-то делать. По факту, при обучении тех же нейронок (а их архитектура описывается кодом на, например, Питоне) код пишется в самую последнюю очередь.
Это потому, что вы реально описываете тут создание конкретной нейросети под конкретную задачу.
А как создавались вообще нейросети?
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, smeeld, Вы писали:
S>>Примером не доказывают.
N>Вообще-то доказывают. Теоремы о существовании в математике доказывают как раз примерами существования искомых объектов. Это называется доказательством с помощью построения или конструктивным доказательством.
В вашем "доказывают как раз" неявно подразумевается квантор общности, или как? (сложно тут прочитать как-то иначе)
Ну в таком случае странно, что вы не добрались хотя бы до очевидного.
Здравствуйте, Poopy Joe, Вы писали:
I>>Разрабатываешь ты не абы как, а именно длобдостижения конкретного результата. А раз так, то надо всегда проверять, достигаешь ли ты его. I>>И вот эта проверка и есть тестирование. PJ>И как в этом убедиться не написав тест для теста?
А что именно вы имеете в виду под "тестом для теста"? Если рекомендации из TDD типа "сначала убедитесь, что тест упал", то это обманка, потому что нет никакой гарантии, что дальше тест молча не сломается.
Поэтому, да, сами тесты тоже надо проверять на живость — чем автоматизированнее, тем лучше.
Здравствуйте, netch80, Вы писали:
S>>>Примером не доказывают.
N>>Вообще-то доказывают. Теоремы о существовании в математике доказывают как раз примерами существования искомых объектов. Это называется доказательством с помощью построения или конструктивным доказательством.
N>В вашем "доказывают как раз" неявно подразумевается квантор общности, или как? (сложно тут прочитать как-то иначе)
Постарайся прочитать. Был тезис: Примером не доказывают. Я его опроверг: конструктивное доказательство как раз строится на примере.
Что ты там увидел, почему решил, что я не в курсе про неконструктивной — я хз.
Здравствуйте, netch80, Вы писали:
N>Полно исследовательских проектов, которые что-то родили совсем не то, что предполагалось изначально. N>См. например историю транзистора.
Посмотрел. Но никакой разработки ПО там не нашёл. И тестов там никто не писал. Или я что-то упустил?
Здравствуйте, Ватакуси, Вы писали:
S>>Наверное, неправильно. В>Неправильно, конечно. В>Проверяется дерево вызовов *внутри микросервиса*. Какая в этом ценность?
Проверяется корректность в логике сервиса, предполагая, что остальные отработали (mock) как надо.
Что значит "внутри"? В тестах, т.е. снаружи эта логика проверяется. Но в изоляции от других.
Если BL тестируемого сервиса поменяется, то тест упадет. Ценно? Вполне.
Здравствуйте, netch80, Вы писали:
N>А что именно вы имеете в виду под "тестом для теста"? Если рекомендации из TDD типа "сначала убедитесь, что тест упал", то это обманка, потому что нет никакой гарантии, что дальше тест молча не сломается. N>Поэтому, да, сами тесты тоже надо проверять на живость — чем автоматизированнее, тем лучше.
То и имею ввиду. Если тест проверяет код на достижение результата, то кто проверяет на то же самое сам тест? А если его проверили только руками, то что мешало так же проверить код, не создавая лишних сущностей?
Смысл тестов в легком отслеживании изменения поведения при рефакторинге и только. TDD это такой забавный карго-культ.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, varenikAA, Вы писали:
N>>>5. Начинаем писать код? AA>>Я говорю про разработку, а не про кодинг.
N>Блин, тогда я ничего не понимаю. А что такое "тестируемый объект", если не код?
Люблю образные аналогии.
Вот мастерская делает деревянные двери.
Дверь кто делает?
Правильно, мастер!
А кто наждачкой ее шлифует?
Подмастерье!
Наждачка здесь это тесты. А подмастерье это кодер.
Ну а мастер это разработчик. Он определяет как будет выглядеть продукт.
Вот ты через TDD написал несуществующую функцию в тесте.
Да в большинстве IDE из-за интелисенса это будет банально неудобно.
Любите одевать штаны через голову? Да пожалуйста!
Здравствуйте, Буравчик, Вы писали:
Б>Не понятно, что понимается под "использование тестирования в качестве метода разработки".
Классический TDD: пишем метод теста и в нем вызываем несуществующую еще функцию из не существующего компонента.
Б>В любом случае без тестов очень трудно поддерживать систему. Б>Рефакторинг затруднен, добавление фич затруднено. С тестами намного удобнее/спокойнее.
Я не против тестов, но иногда замечаю что люди углубляются в кодирование ради кодирования забывая о цели — разработка простого(для расширения и изменения) и удобного(для использования) продукта.
Будь то приложение или библиотека.
Здравствуйте, netch80, Вы писали:
N>Формализация этих требований на языке программирования является частью работы программиста (даже если он будет называться "автоматизированным тестировщиком" или как-то похоже).
Хорошие ЯП не нуждаются в тестах для спецификации. Это и банальные интефейсы и контракты.
Даже в динамичских ЯП это есть всякие https://clojure.org/guides/spec для написания более корректного кода.
А если взять статичные строгие типа Elm, то там вообще тесты это область "программирования в малом", т.е. отладка функций, но разработка компонента через TDD это явный оверхед.
N>Зато известно, что баг, отловленный программистом до прихода к отдельным тестерам, обходится (обычно) в разы дешевле, чем пойманный уже этими тестерами.
Это уже от навыков и опыта зависит, а не от тестов. Стреляет не оружие, а человек.
Здравствуйте, Poopy Joe, Вы писали:
N>>А что именно вы имеете в виду под "тестом для теста"? Если рекомендации из TDD типа "сначала убедитесь, что тест упал", то это обманка, потому что нет никакой гарантии, что дальше тест молча не сломается. N>>Поэтому, да, сами тесты тоже надо проверять на живость — чем автоматизированнее, тем лучше.
PJ>То и имею ввиду. Если тест проверяет код на достижение результата, то кто проверяет на то же самое сам тест? А если его проверили только руками, то что мешало так же проверить код, не создавая лишних сущностей? PJ>Смысл тестов в легком отслеживании изменения поведения при рефакторинге и только. TDD это такой забавный карго-культ.
Что TDD это неработающая методика (в чистом виде) — я согласен. Любая практика больше одноразового кода его нарушает.
Карго-культ или нет — это вопрос уже больше субъективный (opinion-based), чем объективный.
А вот дальше вы начинаете нести полную чушь, игнорируя реальность и устанавливая некорректные логические связи. Потому что:
1. Программные тесты отображают спецификацию к компоненту и позволяют её проверить автоматизированно в любой момент.
Таким образом они ещё и работают регрессионными проверками (если что-то сломали позже, запуск тестов это ловит).
И это делается всеми нормальными авторами софта (заинтересованными в результате).
2. Да, если тест "проверили только руками", то это слабая проверка. Но тесты точно также можно сами проверять автоматизированно, для этого есть минимум две методики:
1) Инверсии — вводится внешняя непрозрачная для логики теста фиксированная модификация, после которой тест может упасть. Проверка заключается в обнаружении планового падения теста.
2) Мутации — код компонента или код теста меняется случайным образом и это не должно пройти незамеченным.
Обе вполне себе почтенные, для мутационного тестирования есть промышленные инструменты.
Ладно, я готов поверить, что вы второго пункта не знаете. Но чтобы про регрессионную роль тестов не знать, это ж как надо не знать тематику?
Здравствуйте, varenikAA, Вы писали:
N>>Формализация этих требований на языке программирования является частью работы программиста (даже если он будет называться "автоматизированным тестировщиком" или как-то похоже). AA>Хорошие ЯП не нуждаются в тестах для спецификации. Это и банальные интефейсы и контракты.
Ага, теперь каким-то образом как туз из рукава появились "хорошие ЯП", которым можно навесить подробные контракты на функциональность компонентов. Которые вообще-то до сих пор не вышли на промышленный уровень и болтаются в лучшем случае после 20й позиции в популярности.
Вы так и будете прыгать с тезиса на тезис?
AA>Даже в динамичских ЯП это есть всякие https://clojure.org/guides/spec для написания более корректного кода. AA>А если взять статичные строгие типа Elm, то там вообще тесты это область "программирования в малом", т.е. отладка функций, но разработка компонента через TDD это явный оверхед.
Повторяю: какая связь тестирования вообще и конкретной TDD? Вы за всю дискуссию так и не поняли, что это разные вещи?
N>>Зато известно, что баг, отловленный программистом до прихода к отдельным тестерам, обходится (обычно) в разы дешевле, чем пойманный уже этими тестерами. AA>Это уже от навыков и опыта зависит, а не от тестов. Стреляет не оружие, а человек.
Это результаты практических наблюдений по отрасли. Ну поспорьте с ними... с ветряной мельницей давно воевали?
Здравствуйте, varenikAA, Вы писали:
AA>Вот мастерская делает деревянные двери. AA>Дверь кто делает? AA>Правильно, мастер! AA>А кто наждачкой ее шлифует? AA>Подмастерье! AA>Наждачка здесь это тесты. А подмастерье это кодер.
Ну да, сделали в два раза больше и петли не в тех местах — ok. Зато наждачкой прошлись.
N>>Блин, тогда я ничего не понимаю. А что такое "тестируемый объект", если не код? AA>Люблю образные аналогии.
Ваш котёнок с дверцей жалобно мяукает и просит избавить его от этого украшения.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Ватакуси, Вы писали:
В>>Я вот сейчас работаю с проектом, где до одного места этих микросервисов, которые ещё засунуты в самописный велосипед. 80% тестов ничего не тестируют, а просто добавляют "покрытие". В>>Там тупо всё mocked.
S>Все правильно, это юнит-тесты, тестирующие модуль изолированно. Для совместного теста надо писать интеграционные тесты.
Разделение на юнит-тесты и интеграционные — терминологическая нелепость.
"Модуль" может состоять из других модулей хоть в 10 уровней иерархии.
Есть функциональные тесты разного уровня. Для всех внутренние сущности работают как обычно (ну, с поправкой на то, что, например, логгинг может быть отключен или иначе настроен), а внешние мокаются или эмулируются (разница тут неважна). По отношению ко внутренним составляющим это интеграционные тесты, а по отношению к внешним — юнит-тесты. Ну и зачем?
Здравствуйте, netch80, Вы писали:
N>>>Вот у меня новая суперсортировка. Я пишу тест: sort([3,2,5,4,1]) == [1,2,3,4,5]. Это дублирование кода сортировки или нет?
ZEN>>Это сравнение возвращаемой функцией sort() ссылки на объявленный в коде массив. Чего вы этим хотите добиться?
N>Вы даже не уточнили, о каком языке идёт речь в этом псевдокоде и какое сравнение участвует, а уже пытаетесь буквоедствовать.
Это то же самое, что пытаться тестировать, ещё не имея кода.
не существует методики ни разработки, ни тестирования, которая может дать гарантию отсутствия ошибок
