V>А ещё из той же серии, писать повторно используемый код тоже вредно, потому что на него тратится в несколько раз больше усилий чтобы проверить несколько различных случаев его использования. Вот и вопрос, писать ли тесты, писать ли повторно используемый код и так далее. Однозначного ответа здесь естественно нет, зависит от множества факторов одним из которых является сам программист.
Код не придётся использовать повторно, если каждый раз достаточно быстро увольняться и устраиваться в другое место с большей зарплатой.
Данное сообщение является художественным произведением и освещает вымышленные события в вымышленном мире. Все совпадения с реальностью являются случайными. Не является инвестиционной рекомендацией.
Здравствуйте, velkin, Вы писали:
AA>>Тестирование лишь способ автоматизировать выполнение написанного кода. AA>>Использовать его в качестве метода разработки бесполезно и даже вредно.
V>А ещё из той же серии, писать повторно используемый код тоже вредно, потому что на него тратится в несколько раз больше усилий чтобы проверить несколько различных случаев его использования. Вот и вопрос, писать ли тесты, писать ли повторно используемый код и так далее. Однозначного ответа здесь естественно нет, зависит от множества факторов одним из которых является сам программист.
Писать код вообще вредно, не только для программиста но и для заказчика. Им обоим самом деле это всё не нужно. Это отдаляет от природы, от деревни, от общины.
Здравствуйте, varenikAA, Вы писали:
AA>>>Это очевидно, сначала нужен тестируемый объект.
N>>С какого "начала"?
AA>разработка через тестирования начинается с написания тестов, когда тестировать нечего, если вы делаете так, то это очень странно.
А, то есть таки речь про TDD, а не про тестирование в целом, я угадал.
Рекомендую тогда исправить заголовок: сейчас он неадекватен.
Про TDD хочу сказать, что в частных случаях это очень полезная и удобная методика, когда или есть твёрдая уверенность в требуемой функциональности, или когда удобно делать преодоление
Здравствуйте, Sharov, Вы писали:
I>>Нужно понимать, что 100% это всего лишь про строчки, а не ветвления. S>А разве в 100% ветвления не входят?
Вот такой код:
void f(int i) {
var list = new ArrayList<String>();
if(i % 2 == 0) list.add("hi");
if(i % 3 == 0) list.add("bye");
use(list);
}
покрывается на 100% по ветвлениям тестами f(2) и f(3). Но никак не тестируются ситуации, когда list пустой, например.
Так что покрытие ветвлений — этого мало. Надо ещё покрывать все пути исполнения. Но таких путей экспоненциально много, поэтому нереально.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, varenikAA, Вы писали:
AA>Это очевидно, сначала нужен тестируемый объект.
Вообще-то исследовательские разработки ведутся как раз наоборот: сначала тесты, а потом код. Точнее, сначала описывают требования, потом под них пишут тесты, а уже потом начинают разработку.
Поясню:
1. Тебе на селфи на телефоне надо искать лица и улучшать их, чтобы девочкам нравились селфи именно с этого телефона.
2. Мы начинаем писать код? Нет, нам нет смысла его писать, потому что непонятно, с чем вообще он будет работать. Мы начинаем собирать фотки!
3. Нашли 10000 фоток. Начинаем писать код? Нет, мы наймём ребят, которые на всех фото выделят ручками лица.
4. Лица выделены. Начинаем писать код? Нет, мы наймём дизайнеров, которые в фотошопе улучшат кождое из этих фото на свой вкус.
5. Начинаем писать код? Нет, мы придумываем критерий, по которому будем считать, что лицо на фото найдено максимально верно (IoU наример) и улучшено максимально хорошо.
6. Начинаем писать код? Нет, мы разобьём выборку на 3 части: обучающую, тестовую и валидационную, выберем библиотеку для обучения нейросетей и настроим для обучения и валидации.
7. Начинаем писать код? Да, ведь у нас уже есть всё, для тестирования результата. Сочиняем архитектуру нейросети, обучаем и следим за тем, как она по подготовленным данным обучается.
8. Обучили. Пишем код для того, чтобы отправить обученную нейросеть в продакшен на телефончик.
Любая другая последовательность действий изначально обречена на провал. Надо сначала собрать данные, на которых будет работать программа. Надо описать программно сценарии работы и критерии правильности и только потом есть смысл что-то делать. По факту, при обучении тех же нейронок (а их архитектура описывается кодом на, например, Питоне) код пишется в самую последнюю очередь.
Здравствуйте, netch80, Вы писали:
N>Что TDD это неработающая методика (в чистом виде) — я согласен. Любая практика больше одноразового кода его нарушает.
О чем спор тогда?
N>А вот дальше вы начинаете нести полную чушь, игнорируя реальность и устанавливая некорректные логические связи. Потому что:
"Потому что" тут может быть только один — тебе выдали сертификат носителя истины, но ты забыл его привести. Иначе это просто твое частное мнение.
N>1. Программные тесты отображают спецификацию к компоненту и позволяют её проверить автоматизированно в любой момент.
Нет, обычно, не отображают. Да, можно выразить спецификацию через тесты. Так делают через проперти тесты. Проблема с этим подходом только одна: за пределами демонстрационных примеров, типа разворота списка, это сделать достаточно сложно. Во всяком случае в дикой природе встречается в крайне ограниченном виде.
N>Таким образом они ещё и работают регрессионными проверками (если что-то сломали позже, запуск тестов это ловит).
Если бы этот подход работал, то в программе бы не было багов. Вообще. Я думаю ты даже сам в эту "чушь" не веришь. А с чего начинается правильная работа на багом? Правильно, с написания очередного теста для него. Что доказывает неполноту предыдущей спецификации.
N>1) Инверсии — вводится внешняя непрозрачная для логики теста фиксированная модификация, после которой тест может упасть. Проверка заключается в обнаружении планового падения теста. N>2) Мутации — код компонента или код теста меняется случайным образом и это не должно пройти незамеченным.
Ничего из этого не доказывает ни правильность теста, ни полноту спецификации. Теперь и ты знаешь. Не благодари.
Здравствуйте, varenikAA, Вы писали:
AA>Тестирование лишь способ автоматизировать выполнение написанного кода. AA>Использовать его в качестве метода разработки бесполезно и даже вредно.
Ещё code coverage есть. Вот уж религия, и ради большого code coverage зачастую пишутся фуфловые тесты, которые ничего не тестируют, зато покрывают.
Здравствуйте, varenikAA, Вы писали:
I>>Или предложишь сэкономить и запушить сразу в прод? AA>не знаю как вы, я сначала пишу код, потом тестирую
То есть, все равно нужны тесты, в которых, по твоим словам, нету смысла
AA>По настоящему работа программиста оценивается рабочим экземпляром.
Рабочий экземпляр это только самое начало. Скажем, в норме рабочих экземпляров бывает и по десятку.
Оценивает пригодность того или иного рабочего экземпляра именно тестировщик.
AA>А чтобы в коде не было багов, нужен соответствующий компилятор.
Какой компилятор найдет алгоритмическую ошибку?
Давай на примере фильтра, годится? Ну, скажем, ты попутал some и all, findFirst и filter, и тд.
AA>Тестировщик про которого вы пишете это вероятно проверка работы user cases
Именно.
AA>в бета-версии продукта?
Разумеется. Именно тестировщик определяет степень готовности, т.е. именно он говорит, что уже альфа, бета, релиз-кандидат и тд.
AA>конечно влияет на процесс разработки. цикл разработки на мой взгляд выглядит примерно так: ( -> идея -> реализация -> проверка -> улучшение ->).
А еще оказывается, что идея не летает, и все надо начинать с начала. Цель тдд — выявить нерабочее решение как можно раньше.
Здравствуйте, netch80, Вы писали:
AA>>Использовать его в качестве метода разработки бесполезно и даже вредно.
N>Докажите.
Это очевидно, сначала нужен тестируемый объект.
это как поставить телегу впереди лошади.
Возvожно в каких-то ЯП из-за их слабости этот метод бы и подошел, но я думаю все же лучше сразу проектировать рабочий компонент.
а при помощи тестирования лишь проверять качество(привет, Property-based testing).
Здравствуйте, varenikAA, Вы писали:
AA>>>Использовать его в качестве метода разработки бесполезно и даже вредно.
N>>Докажите.
AA>Это очевидно, сначала нужен тестируемый объект.
С какого "начала"?
AA>это как поставить телегу впереди лошади.
Какую телегу и впереди какой лошади? Прошу выражаться ясно и без сомнительных аналогий.
AA>Возvожно в каких-то ЯП из-за их слабости этот метод бы и подошел, но я думаю все же лучше сразу проектировать рабочий компонент.
"Лучше быть богатым и здоровым, чем бедным и больным" (tm)
Да, лучше сразу проектировать рабочий компонент. Только вот проблема — не получается.
AA>а при помощи тестирования лишь проверять качество(привет, Property-based testing).
У меня возникло подозрение, что вы на самом деле говорите не про тестирование в общем, а про test-driven development.
Если так, то я согласен, что в чистом виде эта методология не годится ни для чего, кроме одноразового кода, написанного с нуля. Любое её реальное применение так или иначе нарушает какие-то её каноны.
Но ни в коем случае нельзя такого говорить про тестирование вообще, потому что оно является почти единственным способом _показать_ с управляемой достоверностью, что задание понято и реализовано правильно.
Здравствуйте, smeeld, Вы писали:
S>Ты когда последний раз математику открывал?
То есть опять голословие и незнание понятие "конструктивное доказательство" в математике.
N>>Не надо покрывать все случаи жизни, надо лишь покрыть формальные требования, а также крайние случаи. Сложная система совсем без тестов бесполезна. S>Ясно, разраб хеллоуворлдов, или очередной ыффективный аркитектор.
Здравствуйте, varenikAA, Вы писали:
AA>Тестирование лишь способ автоматизировать выполнение написанного кода. AA>Использовать его в качестве метода разработки бесполезно и даже вредно.
А ещё из той же серии, писать повторно используемый код тоже вредно, потому что на него тратится в несколько раз больше усилий чтобы проверить несколько различных случаев его использования. Вот и вопрос, писать ли тесты, писать ли повторно используемый код и так далее. Однозначного ответа здесь естественно нет, зависит от множества факторов одним из которых является сам программист.
Здравствуйте, varenikAA, Вы писали:
AA>Потому что это пустая трата времени. AA>потом придется все это продублировать в рабочем коде. AA>и вы не просто потеряете время, но и вполне вероятно "не увидите леса за деревьями".
Давай я тебе на аналогии проиллюстрирую.
Вот, к примеру, надо тебе построить авто. Ты чертежи сперва нарисуешь, или начнешь на глазок железки пилить, а чертежи потом по факту нарисуешь?
Тесты в случае TDD это формальная спецификация, требование к тому что тебе надо реализовать. Можно, конечно, написать текст и писать по нему код с поправкой на испорченный телефон. А можно написать тест, который невозможно понять не так.
Здравствуйте, varenikAA, Вы писали:
AA>Тестирование лишь способ автоматизировать выполнение написанного кода.
Верёвка есть вервие простое, угу.
AA>Использовать его в качестве метода разработки бесполезно и даже вредно.
Ты продолжаешь раз за разом делать одну и ту же ошибку — оценивать профессиональные инструменты с точки зрения человека, который просто балуется с программированием.
Здравствуйте, Nuzhny, Вы писали:
N>И тут должен следовать пример, подтверждающий правоту твоих слов.
Примером не доказывают. Нужно обобщённое обоснование. Оно выше, про условно бесконечное время, нужное для написани тестов, которые бы покрывали всё в случае сложной системы. А частичное покрытие-это те самые деревья, за которыми не видно леса, о чём упоминал TC.
Здравствуйте, netch80, Вы писали:
N>А что именно вы имеете в виду под "тестом для теста"? Если рекомендации из TDD типа "сначала убедитесь, что тест упал", то это обманка, потому что нет никакой гарантии, что дальше тест молча не сломается. N>Поэтому, да, сами тесты тоже надо проверять на живость — чем автоматизированнее, тем лучше.
То и имею ввиду. Если тест проверяет код на достижение результата, то кто проверяет на то же самое сам тест? А если его проверили только руками, то что мешало так же проверить код, не создавая лишних сущностей?
Смысл тестов в легком отслеживании изменения поведения при рефакторинге и только. TDD это такой забавный карго-культ.
Здравствуйте, Sharov, Вы писали:
S>>>Так, наверное, почти любой процесс можно автоматизировать. I>>Ок, покажи, как ты автоматизируешь проверку тестов на вечнозеленость.
S>Что такое вечнозеленость? Проверить, прошел тест или нет, не то?
Вечнозеленый тест, это который никогда не фейлится, что бы ни ломалось в коде.
Тесты зеленые — компоненты не работают, степень покрытия — 99% строк в коде.
S>Ну разумеется, если для верфикации нужно писать на спец. диалектах, а не на, скажем, С99. Там просто так память не выделишь.
А что, диалект как то решает проблему "и так сойдёт" ?
Здравствуйте, Ikemefula, Вы писали:
I>Вот твой property-based I>
I>const fc = require('fast-check');
I>fc.assert(
I> fc.property(
I> fc.string(), fc.string(), fc.string(),
I> (a, b, c) => contains(b, a+b+c))
I>);
I>
I>кто тебе мешает написать такой код еще до того, как contains объявлена?
Потому что это пустая трата времени.
потом придется все это продублировать в рабочем коде.
и вы не просто потеряете время, но и вполне вероятно "не увидите леса за деревьями".
Здравствуйте, iZEN, Вы писали:
N>>Вот у меня новая суперсортировка. Я пишу тест: sort([3,2,5,4,1]) == [1,2,3,4,5]. Это дублирование кода сортировки или нет?
ZEN>Это сравнение возвращаемой функцией sort() ссылки на объявленный в коде массив. Чего вы этим хотите добиться?
Вы даже не уточнили, о каком языке идёт речь в этом псевдокоде и какое сравнение участвует, а уже пытаетесь буквоедствовать.
Здравствуйте, varenikAA, Вы писали:
AA>Тестирование лишь способ автоматизировать выполнение написанного кода.
Да. AA>Использовать его в качестве метода разработки бесполезно и даже вредно.
Нет.
Когда ты пишешь тесты, то тесты являются потребителем тестируемого кода, а следовательно, уже на этапе написания тестов, интерфейсы, структура классов становятся продуманнее, более SOLIDными
Здравствуйте, varenikAA, Вы писали:
AA>разработка через тестирования начинается с написания тестов, когда тестировать нечего, если вы делаете так, то это очень странно.
Очень странно делать заявления космического масштаба без каких-то аргументов.
Разработка через тестирование это работающий подход к разработке со своими плюсами и минусами. Нравится тебе он или нет, это вопрос другой.
Здравствуйте, varenikAA, Вы писали:
N>>Почему этого нельзя сделать?
AA>Можно, но зачем? вы пишете тесты или программу? AA>Есть такая профессия тестировщик. Разработчик — лошадь, тестировщик — телега.
Если речь про качество, а не фичи, то все ровно наоборот — тестировщик это лошадь, а телега это разраб.
Здравствуйте, Nuzhny, Вы писали:
N>Вообще-то исследовательские разработки ведутся как раз наоборот: сначала тесты, а потом код.
Иссследовательские разработки хеллуоворлдов. Потому-что на что посерьёзней тестов не непишешься, на это уйдёт время равное времени существования вселенной. Только если на какие-то самые базовые вещи. А неумение реализовать базовый функционал без тестов-это неумение разрабатывать, aka криворукость.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, smeeld, Вы писали:
S>>Примером не доказывают.
N>Вообще-то доказывают. Теоремы о существовании в математике доказывают как раз примерами существования искомых объектов. Это называется доказательством с помощью построения или конструктивным доказательством.
Ты когда последний раз математику открывал?
N>Не надо покрывать все случаи жизни, надо лишь покрыть формальные требования, а также крайние случаи. Сложная система совсем без тестов бесполезна.
Ясно, разраб хеллоуворлдов, или очередной ыффективный аркитектор.
AA>Очевидно же с самого начала, тестирование бесполезно для РАЗРАБОТКИ.
Лучше смотреть английскую версию
Software development is the process of conceiving, specifying, designing, programming, documenting, testing, and bug fixing involved in creating and maintaining applications, frameworks, or other software component
То есть, к разработке относится и программирование, и документация, и проектирование, и багфикс, и мейнтенанс.
Здравствуйте, smeeld, Вы писали:
N>>Вообще-то исследовательские разработки ведутся как раз наоборот: сначала тесты, а потом код.
S>Иссследовательские разработки хеллуоворлдов.
Наоборот. в серьезных проектах сначала прорабатываются требования. Между стартом проекта и стартом разработки бывают проходят месяцы-годы. И нормой является смена подхода.
Здравствуйте, Ватакуси, Вы писали:
В>Для этого есть компиляторы или хотя бы стат. анализаторы.
Ага, есть
В>Я вот сейчас работаю с проектом, где до одного места этих микросервисов, которые ещё засунуты в самописный велосипед. 80% тестов ничего не тестируют, а просто добавляют "покрытие". В>Там тупо всё mocked.
Здравствуйте, Ватакуси, Вы писали:
В>Я вот сейчас работаю с проектом, где до одного места этих микросервисов, которые ещё засунуты в самописный велосипед. 80% тестов ничего не тестируют, а просто добавляют "покрытие". В>Там тупо всё mocked.
Все правильно, это юнит-тесты, тестирующие модуль изолированно. Для совместного теста надо писать интеграционные тесты.
Здравствуйте, Буравчик, Вы писали:
Б>Не понятно, что понимается под "использование тестирования в качестве метода разработки".
Классический TDD: пишем метод теста и в нем вызываем несуществующую еще функцию из не существующего компонента.
Б>В любом случае без тестов очень трудно поддерживать систему. Б>Рефакторинг затруднен, добавление фич затруднено. С тестами намного удобнее/спокойнее.
Я не против тестов, но иногда замечаю что люди углубляются в кодирование ради кодирования забывая о цели — разработка простого(для расширения и изменения) и удобного(для использования) продукта.
Будь то приложение или библиотека.
Здравствуйте, varenikAA, Вы писали:
AA>Здравствуйте, netch80, Вы писали:
AA>мы явно говорим на разных языках.
Вполне возможно. При этом в вашем языке отсутствуют чёткие определения, слова меняют смысл как вздумается не то говорящему, не то самим словам, и в результате никто не может понять смысл сказанного, и остаётся только кивать "да, я тебя тоже уважаю".
Что ж, есть места, где такой язык вполне уместен. Но данная дискуссия как-то не очень входит в их набор.
Здравствуйте, Poopy Joe, Вы писали:
N>>В ваше утверждение — "Если бы этот подход работал, то в программе бы не было багов" — конечно, не верю. Нет причин в него верить. PJ>Я не просил верить в мое утверждение. Я спросил веришь ли ты что в программе нет багов. По определению, если тесты описывают спецификацию и они зеленые, то багов нет. Так ведь? Не?
Конечно, нет. Может, у тебя один тест, который проверяет, как main() разбирает аргументы, и он зелёный
Для того, чтобы с достаточной уверенностью доверять результатам тестов, нужно:
1) Разумность самих тестов (метода, набора тестовых данных), с точки зрения нахождения проблем реализации согласно задаче и выбранному методу.
2) Верификация кода (хотя бы визуальная) на то, что реализован действительно нужный подход (а не поставлен, грубо говоря, большой if на конкретные тестируемые случаи).
3) Достаточное покрытие нужного-по-ТЗ кода тестами (несмотря на всю условность этого понятия).
4) Доверие среде и библиотекам.
Вот после этого можно говорить — не абсолютно, но с практически достаточной уверенностью — про отсутствие багов.
И да, в это я верю. Как-то практика показывает, что именно так и оно и работает
N>>Вы пропустили, что не "выражают", а именно "отображают". Отображение ограниченно, но искусство программиста — в умении выбрать тесты, которые отражают и типовые, и крайние случаи. PJ>И что это отображение дает?
Даёт пункт (1) в списке выше.
N>>И вот, кстати, property-based testing пригодно как минимум для 1, 3 и 4. PJ>Оно пригодно для всех четырех. В теории. На практике какой процент у тебя таких тестов в общем коде? Вот, то-то и оно.
В зависимости от задачи сильно по-разному.
Были, где, грубо говоря, 90%. Сейчас крайне мало — но это потому, что ресурсов нет. А так я бы и сейчас добавил переменных.
N>>Тесты, в отличие от формальной верификации, в принципе не могут покрыть всё. У них и задачи такой нет. Задачи тестов: PJ>Задача тестов одна, я ее упоминал выше. Отслеживать изменение поведение кода при рефакторинге.
Если ты используешь тесты ровно для этого — это твои личные ограничения.
PJ> Т.е. это автоматизация рутинной работы. Все! Они совершенно ничего не гарантируют и никогда на это нельзя полагаться. Просто несколько облегчает жизнь.
Не "несколько", а на порядки.
И не "совершенно ничего не гарантируют", а гарантируют поиск >90% багов в обычном применении. Конкретная доля может быть и 95, и 99%, в зависимости от множества факторов.
Как по мне, этого достаточно, чтобы тратить на них приличный кусок времени (условно говоря, половину).
N>>1. Показать работоспособность для внешнего контроля (заказчик, QA...), который может вообще не интересоваться тем, что в решении есть программная часть и как она устроена. PJ>Поржал. Сдаешь заказчику программу и на демо показываешь, что все тесты пройдены?
А почему ты в этом рассмотрении предполагаешь только внутренние кодовые тесты?
Они могут быть и визуальные, и в режиме чёрного ящика "X на входе — Y на выходе", и массой промежуточных вариантов.
N>>3. Подтвердить корректность внешних постулатов (например, что open() открывает файл согласно пути и ключам, а не звонит в колокольчик). PJ>Есть он будет звонить в колокольчик и открывать файл, то твой тест это скорее всего и не заметит.
Это ловится на других уровнях и другими методами.
N>>Спецификация меняется под задачи. "Неполнота" предыдущей спецификации, а точнее, вообще её отличие (может что-то вообще меняться несовместимо) — норма разработки. Методология должна это учитывать. N>>Точно так же она должна учитывать и то, что может оказаться, что под новую спецификацию ничего не надо менять. И так бывает. PJ>Ниче не понял. Баг это когда ожидается одно, а результат другой. Никакая спецификация тут не меняется.
А кто только что писал про предыдущую спецификацию? Сам уже не помнишь, что писал?
N>>Про полноту спецификации тезис появился только в вашем последнем комментарии. PJ>Потому я отвечал на пост в котором появилось слово спецификация. Внезапно.
OK. Представим себе, что "спецификация" это "полное и точное ТЗ", и пойдём дальше. Так откуда взялась предыдущая спецификация?
N>>О множестве важных деталей и о расстановке принципиальных акцентов. PJ>И в чем заключаются эти акценты?
Ну вот я выше и описал. Разница между "ничего не гарантируют" и "статистически гарантируют поиск >90% ошибок", по-твоему, важна или нет?
N>>Ап ту ю. Можете игнорировать, но потом нарвётесь — вспомните. PJ>Нарвусь на что? Я очень переживаю о том считаешь ли ты мои слова чушью, это крайне важно для меня.
Сарказм понят, но не оценён. Нарвёшься на то, что будешь отказываться от доступных средств из-за гордыни.
N>Конечно, нет. Может, у тебя один тест, который проверяет, как main() разбирает аргументы, и он зелёный
Во, ты начинаешь что-то подозревать. Прикол в том, что это ничем не отличается ни от 1000, ни от 10000.
N>1) Разумность самих тестов (метода, набора тестовых данных), с точки зрения нахождения проблем реализации согласно задаче и выбранному методу.
И как ты проверяешь разумность?
N>2) Верификация кода (хотя бы визуальная) на то, что реализован действительно нужный подход (а не поставлен, грубо говоря, большой if на конкретные тестируемые случаи).
Жесть какая...
N>3) Достаточное покрытие нужного-по-ТЗ кода тестами (несмотря на всю условность этого понятия).
Достаточное это какое?
N>4) Доверие среде и библиотекам.
А нафига тогда все предыдущие?
N>Вот после этого можно говорить — не абсолютно, но с практически достаточной уверенностью — про отсутствие багов.
И че хоть раз такое происходило? Ну, только честно.
N>И да, в это я верю. Как-то практика показывает, что именно так и оно и работает
В стране с единорогами?
N>Были, где, грубо говоря, 90%. Сейчас крайне мало — но это потому, что ресурсов нет. А так я бы и сейчас добавил переменных.
Охотно верю, был демо проект, где 90% и реальный код, где их почти нет. Я ровно об этом.
N>Если ты используешь тесты ровно для этого — это твои личные ограничения.
Увы, не мои. Это ограничение самой методики. Вот честно, хотелось бы иметь волшебную технологию уровня "компилируется — в продакшн"
N>А почему ты в этом рассмотрении предполагаешь только внутренние кодовые тесты?
Потому что речь о ТDD. Впрочем, заказчика вообще никакие тесты не интересуют. Я, по-крайней мере, таких не видел.
N>Это ловится на других уровнях и другими методами.
Какими?
N>А кто только что писал про предыдущую спецификацию? Сам уже не помнишь, что писал?
Я вообще не понял, что ТЫ написал. Я либо впервые использовал слово спецификация, либо использовал его до этого. Оба утверждения твои и оба они не могут быть верными одновременно.
N>OK. Представим себе, что "спецификация" это "полное и точное ТЗ", и пойдём дальше. Так откуда взялась предыдущая спецификация?
I'm lost. Полное и точное ТЗ, это функциональные требования к системе, это функциональные тесты, в лучшем случае.
Спецификация о которой идет речь это спецификация на отдельные куски кода, которые ты покрываешь тестами. Представим, что теплое это мягкое и пойдем дальше.
N>Ну вот я выше и описал. Разница между "ничего не гарантируют" и "статистически гарантируют поиск >90% ошибок", по-твоему, важна или нет?
Нет, разумеется. Гарантия понятия бинарное, она либо есть, либо ее нет. И нет, тесты этого не гарантируют. Все что гарантируют тесты, это если у тебя измениться поведение функции которую проверяет тест, при условии, что тест проверяет конкретный случай, то он это покажет.
N>Сарказм понят, но не оценён. Нарвёшься на то, что будешь отказываться от доступных средств из-за гордыни.
От каких доступных средств я отказываюсь? От тестов? Это ты сам придумал.
От построения из них карго-культа? Так это ты нарвешься, думая, что они тебе чего-то там гарантируют.
Здравствуйте, Poopy Joe, Вы писали:
N>> перед этим запуском в Jenkins было поймано и исправлено 300-400. PJ> Вам надо ваш процесс переименовать с разработки через тестирование, на разработку через багфиксы. N>>Цифры меняются, соотношение примерно похоже на это. PJ>Ну, я хотя бы понял, что у вас называется "отсутствием багов". Оказалось, что просто общаемся из разных планов бытия.
Это очень прикольно, учитывая, что 1) я никогда не говорил, что ведём "разработку через тестирование", 2) никогда не утверждал отсутствие багов как результат применения тестов.
С кем ты тут споришь — не знаю, но это не я. Кто там у тебя на твоём плане бытия — не в курсе.
На этом я прекращаю. Продолжение будет возможно с собеседником, который общается со мной, а не с неизвестными астральными проекциями.
Здравствуйте, Ikemefula, Вы писали:
S>>Ну почему же, есть же соотв. инструменты верификации. Или, например, у нас КА с большим кол-вом состояний и т.п. I>Каким образом понять, что некто воспользовался этим инструментом, а не накида КА на глазок?
1)КА реализуется программистом, верфицируется кодом.
2)Ответ на вопрос выше -- соотв. процессом.
I>Каким образом понять, что интеграция этого КА сделана как положено, а не просто затычкой вида "и так сойдет" ?
Соотв. процессом.
Если пилится софт для каких-то космических миссий, где запуск стоит 100млн$ долларов, и делается только один раз --
то только соотв. организацией и процессами.
Под процессом имеется в виду соотв. инструменты, системы сборки, тесты, code review и, вероятно, много чего еще.
На глазок в подобным проектах никто ничего не делает.
То же самое и для авионики и подобных критических систем.
Но речь о том, что софт вполне себе можно верифицировать.
А ошибки будут либо на уровне тз (метры с дюймами попутали, читал где-то про какой-то луноход или что-то в этом роде:
в одном месте дюймы, в другом метры -- ну и что-то куда улетело не туда). В тз четко это не было прописано, поэтому каждый
модуль мог делать по своему. Либо ошибки железа. Но это др. история.
Здравствуйте, Sharov, Вы писали:
I>>Вечнозеленый тест, это который никогда не фейлится, что бы ни ломалось в коде. I>>Тесты зеленые — компоненты не работают, степень покрытия — 99% строк в коде.
S>Ну значит требовать 100% покрытия.
Это или невозможно, вообще говоря, в большинстве случаев, или же этот 1% будет таким же как и остальные 99%.
S>>>Ну разумеется, если для верфикации нужно писать на спец. диалектах, а не на, скажем, С99. Там просто так память не выделишь. I>> А что, диалект как то решает проблему "и так сойдёт" ?
S>т.е. сотрудники не позволяют себе "и так сойдет", а делают все оптимально возможным образом + S>минимум аджайла, когда нужно было вчера и т.п. подобные организационные вещи. Т.е. личные кач-ва сотрудников + соотв. процессы. S>А как иначе?
Не стоит вообще не пытаться решать обозначеную проблему ни автоматизацией, ни кодом, ни покрытием, ни тестами-тестов.
Можно, например, внедрять код-ревью в котором верификация решения как обязательный чек поинт.
Собственно, почти всегда за такими вот тестами кроется и код, который писался ровно с таким же отношением к работе.
Людей замеченых в написании подобных решений отстранять, если не хотят работать иначе.
S>>А как такое возможно в случае 100%? I>Элементарно — тесты написаны кое как. I>Более того, когда менеджеры спускают требование 100% именно так и случается — вечнозеленые тесты повсюду, абы достичь этих процентов. I>По этой причине никогде не нужно задирать планку выше разумного.
За исключением тех случаев, когда эти 100% действительно нужны.
Здравствуйте, Sharov, Вы писали:
I>>Элементарно — тесты написаны кое как. I>>Более того, когда менеджеры спускают требование 100% именно так и случается — вечнозеленые тесты повсюду, абы достичь этих процентов. I>>По этой причине никогде не нужно задирать планку выше разумного.
S>За исключением тех случаев, когда эти 100% действительно нужны.
Это не добавляет качества, а количество работы удесятеряет. Стоит покрывать не строчки кода, а ключевые кейсы. Здесь проценты не зафиксируешь, зато эффекта будет гораздо больше.
Нужно понимать, что 100% это всего лишь про строчки, а не ветвления.
То есть, покрыв 100% строчек можно нисколечко не приблизиться к покрытию основных кейсов.
Считать ветвления еще не научились, а простой подсчет говорит о том, что покрытие ветвлений требует астрономическое количество тестов.
Зато покрытие основных кейсов вполне может дать покрытие 80% строчек. Остальное покроется тестами верхнего уровня, тестами на стейджинге и тд.
Здравствуйте, ·, Вы писали:
I>>Отсюда понятно, почему бОльшая часть инструментов про покрытие оперирует строчками. ·>Ну и в догонку: ·>
The essence of this observation is that larger programs tend to be more complex and to have more defects. Reducing the cyclomatic complexity of code is not proven to reduce the number of errors or bugs in that code.
Собственно, логично — уменьшили какую-то ничтожно малую часть всех путей. Как это повлияло на все возможные пути — не ясно, т.к. их количество исчисляется астрономическими величинами.
Единственно, что можно утверждать, это меньшая цикломатическая сложность дает более понятный для человека код, а следовательно и более управляемый.
Соответсвенно можно лучше покрыть тестами, можно лучше покрыть всякими ассертами(предусловия, постусловия и тд), легче выявить проблемы на код-ревью. Но это дополнительная работа. Без этой дополнительной работы совсем не ясно, каким образом уменьшение цикломатической сложности уменьшит количество багов.
Здравствуйте, Osaka, Вы писали:
O>Код не придётся использовать повторно, если каждый раз достаточно быстро увольняться и устраиваться в другое место с большей зарплатой.
Т.е повторное использование программиста тоже исключаем для снижения общей вредности?
Здравствуйте, varenikAA, Вы писали:
N>>Докажите.
AA>Это очевидно, сначала нужен тестируемый объект.
Не нужен.
AA>Возvожно в каких-то ЯП из-за их слабости этот метод бы и подошел, но я думаю все же лучше сразу проектировать рабочий компонент.
Лучше и писать сразу без ошибок.
Рабочий вариант как правило на старте неизвестен. Если у тебя не так, это значит, ты занимаешься задачами, которые уже перерос.
AA>а при помощи тестирования лишь проверять качество(привет, Property-based testing).
А как ты качество понимаешь, раз оно у тебя в проектировании отсутствует?
Вот твой property-based
const fc = require('fast-check');
fc.assert(
fc.property(
fc.string(), fc.string(), fc.string(),
(a, b, c) => contains(b, a+b+c))
);
кто тебе мешает написать такой код еще до того, как concat объявлена?
Здравствуйте, varenikAA, Вы писали:
AA>Потому что это пустая трата времени. AA>потом придется все это продублировать в рабочем коде.
Что именно "всё это" "придётся продублировать"?
Вот у меня новая суперсортировка. Я пишу тест: sort([3,2,5,4,1]) == [1,2,3,4,5]. Это дублирование кода сортировки или нет?
Вот contains, как у Ikemefula. Сделан на алгоритме Бойера-мура (там, где табличка минимальных смещений для символа). Где дублирование кода?
AA>и вы не просто потеряете время, но и вполне вероятно "не увидите леса за деревьями".
Чтобы видеть лес, тесты добавляются (или просто активируются, снимая пометку #[NotYet]) постепенно.
Здравствуйте, netch80, Вы писали:
N>Вот у меня новая суперсортировка. Я пишу тест: sort([3,2,5,4,1]) == [1,2,3,4,5]. Это дублирование кода сортировки или нет?
на момент написания тест sort уже существует? тогда ок, проверяется рабочий код.
Здравствуйте, varenikAA, Вы писали:
I>>Тестирование это проверка соответствия результата требованиям.
AA>И в проде не случалось ни разу ошибки после вашего тестирования?
не существует методики ни разработки, ни тестирования, которая может дать гарантию отсутствия ошибок
Качество это всего лишь степень соответствия требованиям, которая вобщем есть вероятность в зависимости от следующих вещей
1. качество самих требований, упс, рекурсия!
2. методика испытаний и процесс тестирования
3. технологии разработки
4. подход к проектированию
5. квалификация команды
6. процесс разработки
Точно так же и в security не сущетсвует способа дать гарантию отсутствия любых уязвимостей.
Собственно, это не повод отказываться от тестирования, т.к. именно здесь мы убеждаемся, что
1. методы а и б работают на предложенном множестве данных.
2. компоненты обладают нужным поведением
3. модуль, пакет предоставляют нужные функциональные возможности
4. приложение умеет нужные функции, см перечень
5. приложение покрывает все известные сценарии, см перечень сценариев
6. приложение покрывает все критические кейсы, см перечень кейсов
Здравствуйте, varenikAA, Вы писали:
I>>кто тебе мешает написать такой код еще до того, как contains объявлена?
AA>Потому что это пустая трата времени. AA>потом придется все это продублировать в рабочем коде.
Не надо ничего дублировать! Следующий шаг — a+b+c надо выделить в отдельную функцию. И нет никакого дублирования
AA>и вы не просто потеряете время, но и вполне вероятно "не увидите леса за деревьями".
Наоборот, изначально нужно представлять чего ты хочешь добиться. Вот эти ожидания и фиксируются тестами.
Например, в моем примере ожидание вполне понятное — свойство самого concat
Вначале пишем тест для свойства, а потом выделяем уже реализацию.
На самом деле в ТДД непринципиально когда именно ты пишешь тест, до или после.
Часть задач лучше решается, если писать тесты до, часть задачь — если тесты после.
Здравствуйте, varenikAA, Вы писали:
AA>Здравствуйте, netch80, Вы писали:
N>>Вот у меня новая суперсортировка. Я пишу тест: sort([3,2,5,4,1]) == [1,2,3,4,5]. Это дублирование кода сортировки или нет?
AA>на момент написания тест sort уже существует?
Какая разница?
AA> тогда ок, проверяется рабочий код.
А если ещё не существует — задаётся требование к результату функции (его проекция в виде конкретного тесткейса).
Почему этого нельзя сделать?
И вообще вопрос был в другом: откуда предыдущее утверждение про дублирование кода? Вы ушли в сторону.
Здравствуйте, netch80, Вы писали:
N>А если ещё не существует — задаётся требование к результату функции (его проекция в виде конкретного тесткейса). N>Почему этого нельзя сделать?
Можно, но зачем? вы пишете тесты или программу?
Есть такая профессия тестировщик. Разработчик — лошадь, тестировщик — телега.
НС>Давай я тебе на аналогии проиллюстрирую. НС>Вот, к примеру, надо тебе построить авто. Ты чертежи сперва нарисуешь, или начнешь на глазок железки пилить, а чертежи потом по факту нарисуешь?
Именно так, сначала рисуется диаграмма/блок схема. но это не тесты. так ведь? Это именно не формализованный концепт решения.
НС>Тесты в случае TDD это формальная спецификация, требование к тому что тебе надо реализовать. Можно, конечно, написать текст и писать по нему код с поправкой на испорченный телефон. А можно написать тест, который невозможно понять не так.
Согласен, но это громоздкое и не эффективное решение. Тесты должны рождаться когда есть что тестировать. Иначе это напоминает игры умственно отсталого ребенка: смотрите тесты не собираются, добавим заглушку, вау — тест пройден! именно такое описание TDD я встречал.
Как сказал Рич Хикки:
Вопрос: Что там случилось с каждым жучком?
Ответ: они прошли проверку типа, и они прошли все тесты.
Проведение тестов не должно побуждать кого-либо менять код без осторожности.
И представим себе, что у вас в команде выделенный тестировщик.
Что тогда с TDD?
Разработчик будет ждать от тестировщика решение?
Здравствуйте, varenikAA, Вы писали:
AA>Именно так, сначала рисуется диаграмма/блок схема. но это не тесты.
Не надо на аналогиях строить доказательства, это просто иллюстрация.
AA>Согласен, но это громоздкое и не эффективное решение.
Практика показала, что довольно эффективное. Хотя, конечно, бывает по разному.
AA> Тесты должны рождаться когда есть что тестировать.
А если в результате тестирования оказалось, что тестируемый код придется основательно переписать, иначе он не пройдет тесты? Это тоже, по твоему, эффективно?
Здравствуйте, varenikAA, Вы писали:
AA>Именно так, сначала рисуется диаграмма/блок схема. но это не тесты. так ведь? Это именно не формализованный концепт решения.
А далее нужно проверить решение практикой — те самые тесты.
Или предложишь сэкономить и запушить сразу в прод?
AA>И представим себе, что у вас в команде выделенный тестировщик. AA>Что тогда с TDD?
Остается, как есть. Тестировщик занят теми тестами, которые в тдд никогда не пишутся — сценарии, кейсы для всего приложения в целом.
То есть, имеем внятную границу. На практике разработчик залазит на территорию тестировщика, изредка, во время багфикса. И то, если репозиторий общий. Наоборот — никогда.
AA>Разработчик будет ждать от тестировщика решение?
Похоже, про роли разработчика и тестировщика ты из книжек узнал.
Например, работает ли скроллбар корректно — ответственность разработчика. А вот тестер должен убедиться, что юзер может пройти весь сценарий с ответвлениями и вариациями.
По настоящему работа программиста оценивается рабочим экземпляром.
А чтобы в коде не было багов, нужен соответствующий компилятор.
Тестировщик про которого вы пишете это вероятно проверка работы user cases
в бета-версии продукта? это не имеет отношения к TDD. Точнее любой фибек от кого бы он ни был
конечно влияет на процесс разработки. цикл разработки на мой взгляд выглядит примерно так: ( -> идея -> реализация -> проверка -> улучшение ->).
Здравствуйте, smeeld, Вы писали:
S>Иссследовательские разработки хеллуоворлдов. Потому-что на что посерьёзней тестов не непишешься, на это уйдёт время равное времени существования вселенной. Только если на какие-то самые базовые вещи. А неумение реализовать базовый функционал без тестов-это неумение разрабатывать, aka криворукость.
И тут должен следовать пример, подтверждающий правоту твоих слов.
Здравствуйте, smeeld, Вы писали:
S>Примером не доказывают.
Вообще-то доказывают. Теоремы о существовании в математике доказывают как раз примерами существования искомых объектов. Это называется доказательством с помощью построения или конструктивным доказательством.
S>Нужно обобщённое обоснование. Оно выше, про условно бесконечное время, нужное для написани тестов, которые бы покрывали всё в случае сложной системы. А частичное покрытие-это те самые деревья, за которыми не видно леса, о чём упоминал TC.
Не надо покрывать все случаи жизни, надо лишь покрыть формальные требования, а также крайние случаи. Сложная система совсем без тестов бесполезна.
Здравствуйте, varenikAA, Вы писали:
AA>Тестирование лишь способ автоматизировать выполнение написанного кода. AA>Использовать его в качестве метода разработки бесполезно и даже вредно.
Не понятно, что понимается под "использование тестирования в качестве метода разработки".
В любом случае без тестов очень трудно поддерживать систему.
Рефакторинг затруднен, добавление фич затруднено. С тестами намного удобнее/спокойнее.
I>Разрабатываешь ты не абы как, а именно для достижения конкретного результата. А раз так, то надо всегда проверять, достигаешь ли ты его. I>И вот эта проверка и есть тестирование.
И как в этом убедиться не написав тест для теста?
S>Иссследовательские разработки хеллуоворлдов. Потому-что на что посерьёзней тестов не непишешься, на это уйдёт время равное времени существования вселенной. Только если на какие-то самые базовые вещи.
Совершенно верно. Если посадить писать тесты дураков.
Тестировать базовый функционал на уровне юнитов требует линейного количество тестов.
Но поскольку дураки в тесты не умеют, они будут сначала ждать, пока не накопится тестируемый функционал и попытаются тестировать систему в целом. И очень быстро обнаруживают, что число тестов растет экспоненциально от числа юнитов, составляющих систему.
S>А неумение реализовать базовый функционал без тестов-это неумение разрабатывать, aka криворукость.
Здравствуйте, varenikAA, Вы писали:
AA>Здравствуйте, netch80, Вы писали:
N>>А если ещё не существует — задаётся требование к результату функции (его проекция в виде конкретного тесткейса). N>>Почему этого нельзя сделать?
AA>Можно, но зачем? вы пишете тесты или программу?
Написание программы невозможно без хотя бы неформального оформления требований к программному компоненту.
Критической частью функциональности тестов является выражение и проверка этих требований.
Формализация этих требований на языке программирования является частью работы программиста (даже если он будет называться "автоматизированным тестировщиком" или как-то похоже).
AA>Есть такая профессия тестировщик.
Не вижу тут смысла ни в прямой, ни в обратной аналогии с телегой и лошадью.
Скорее это две лошади разного характера в одной телеге.
Зато известно, что баг, отловленный программистом до прихода к отдельным тестерам, обходится (обычно) в разы дешевле, чем пойманный уже этими тестерами.
Б>В любом случае без тестов очень трудно поддерживать систему.
Мотря какая система и мотря какие тесты.
Б>Рефакторинг затруднен, добавление фич затруднено. С тестами намного удобнее/спокойнее.
При богомерзких микросервисах в "облаках" это совсем не удобно. И вообще не добавляет спокойства. Упасть может буквально всё и в любой момент времени. И по любой причине.
Здравствуйте, Poopy Joe, Вы писали:
I>>Разрабатываешь ты не абы как, а именно для достижения конкретного результата. А раз так, то надо всегда проверять, достигаешь ли ты его. I>>И вот эта проверка и есть тестирование. PJ>И как в этом убедиться не написав тест для теста?
Точно так же, как проверяем, пользуется ли разработчик головой или нет.
Задача "сторожить сторожа" возникает во всех областях, где необходим контроль хоть чего нибудь.
0 пишем внятные требования к качеству тестов и проверяем, соблюдаетсли ли оно
1 методики, подходы
2 подготовка персонала
3 аудит
4 ревью
5 инструменты
6 иногда таки пишется тест для теста
Здравствуйте, Ватакуси, Вы писали:
Б>>Рефакторинг затруднен, добавление фич затруднено. С тестами намного удобнее/спокойнее. В>При богомерзких микросервисах в "облаках" это совсем не удобно. И вообще не добавляет спокойства. Упасть может буквально всё и в любой момент времени. И по любой причине.
Может. Это не повод отказываться от тестов. Если убрать юнит-тесты, то простое переименование переменной становится причиной еще большего хаоса.
I>Может. Это не повод отказываться от тестов. Если убрать юнит-тесты, то простое переименование переменной становится причиной еще большего хаоса.
Для этого есть компиляторы или хотя бы стат. анализаторы.
Я вот сейчас работаю с проектом, где до одного места этих микросервисов, которые ещё засунуты в самописный велосипед. 80% тестов ничего не тестируют, а просто добавляют "покрытие".
Там тупо всё mocked.
Здравствуйте, Ikemefula, Вы писали:
PJ>>И как в этом убедиться не написав тест для теста?
I>Точно так же, как проверяем, пользуется ли разработчик головой или нет. I>Задача "сторожить сторожа" возникает во всех областях, где необходим контроль хоть чего нибудь. I>0 пишем внятные требования к качеству тестов и проверяем, соблюдаетсли ли оно I>1 методики, подходы I>2 подготовка персонала I>3 аудит I>4 ревью I>5 инструменты I>6 иногда таки пишется тест для теста
Почему нельзя воспользоваться требованиями, методиками, подходами и далее по списку, в отношении решения, а не теста? Этого либо достаточно, либо еще нужен тест для теста для теста...
Здравствуйте, smeeld, Вы писали:
N>>Вообще-то доказывают. Теоремы о существовании в математике доказывают как раз примерами существования искомых объектов. Это называется доказательством с помощью построения или конструктивным доказательством. S>Ты когда последний раз математику открывал?
Человек занимается CV (машинным зрением), Вы хоть один алгоритм из этой области знаете или видели, чтобы про
математику спрашивать? Я не про базовые вещи говорю, а, например, про детекцию чего-либо на фото.
В>>Я вот сейчас работаю с проектом, где до одного места этих микросервисов, которые ещё засунуты в самописный велосипед. 80% тестов ничего не тестируют, а просто добавляют "покрытие". В>>Там тупо всё mocked.
S>Все правильно, это юнит-тесты, тестирующие модуль изолированно. Для совместного теста надо писать интеграционные тесты.
Нет, там вообще ВСЁ mocked
Т.е. тест выгляди так
Mock everything
Call something
Check something called something 1, something 2, etc.
Здравствуйте, Ватакуси, Вы писали:
В>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 тестируемого сервиса поменяется, то тест упадет. Ценно? Вполне.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, varenikAA, Вы писали:
N>>>5. Начинаем писать код? AA>>Я говорю про разработку, а не про кодинг.
N>Блин, тогда я ничего не понимаю. А что такое "тестируемый объект", если не код?
Люблю образные аналогии.
Вот мастерская делает деревянные двери.
Дверь кто делает?
Правильно, мастер!
А кто наждачкой ее шлифует?
Подмастерье!
Наждачка здесь это тесты. А подмастерье это кодер.
Ну а мастер это разработчик. Он определяет как будет выглядеть продукт.
Вот ты через TDD написал несуществующую функцию в тесте.
Да в большинстве IDE из-за интелисенса это будет банально неудобно.
Любите одевать штаны через голову? Да пожалуйста!
Здравствуйте, 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>Вы даже не уточнили, о каком языке идёт речь в этом псевдокоде и какое сравнение участвует, а уже пытаетесь буквоедствовать.
Это то же самое, что пытаться тестировать, ещё не имея кода.
Здравствуйте, Sharowarsheg, Вы писали:
N>>>>Вот у меня новая суперсортировка. Я пишу тест: sort([3,2,5,4,1]) == [1,2,3,4,5]. Это дублирование кода сортировки или нет?
ZEN>>>Это сравнение возвращаемой функцией sort() ссылки на объявленный в коде массив. Чего вы этим хотите добиться?
N>>Вы даже не уточнили, о каком языке идёт речь в этом псевдокоде и какое сравнение участвует, а уже пытаетесь буквоедствовать.
S>Это то же самое, что пытаться тестировать, ещё не имея кода.
Ну, я бы сказал, что общего как раз мало.
До кода есть представления о том, что этот код должен делать. Многие из них уже однозначны. Эти представления можно записать формально. Это больше относится к BDD и ATDD, чем TDD, но TDD представляет собой просто введение этой методики в (некорректный) абсолют.
Второе что составляет постулат в TDD — это продвижение мелкими шагами для удовлетворения тестов и только для этого. Это не подходит во многих случаях (в основном это сложные алгоритмические задачи, где не существует промежуточных этапов по одному тесту), и может быть слишком дорого для клеевого кода, но есть много случаев, когда я нашёл это удобным. В частности, это очень хороший путь разбиения объёмной задачи (от объёма которой опускаются руки) до состоящей из мелких, подъёмных задач.
В комбинации они дают весьма удобное средство ставить задачи для постепенного продвижения с написанием кода.
Ну а если абьюзить средство... тут уже приводили множество крайних примеров, не хочется повторяться.
Здравствуйте, Ватакуси, Вы писали:
I>>Может. Это не повод отказываться от тестов. Если убрать юнит-тесты, то простое переименование переменной становится причиной еще большего хаоса.
В>Для этого есть компиляторы или хотя бы стат. анализаторы.
Компиляторы и стат-анализаторы решают совсем другой класс ошибок. Это необходимое условие для рефакторинга, но этого еще не достаточно.
В>Я вот сейчас работаю с проектом, где до одного места этих микросервисов, которые ещё засунуты в самописный велосипед. 80% тестов ничего не тестируют, а просто добавляют "покрытие". В>Там тупо всё mocked.
Именно. Тесты проверяют моки По этой причине для рефакторинга нужно отказываться от моков, а дизайнить компоненты таким образом, что бы у нас был такой расклад
1. много дешевых value-check тестов, т.е. тесты вида expect(sin(x)).to.eq(y). Сюда же относится property-based тесты.
2. компромис — если нет способа как п.1, напримпер, стейтфул-механика, то тестируем через state-check. Разумеестся, если можно отказаться от стейт-фул логики, то все тесты перепиливаются как п.1
3. поведенческие — если нет способа п1 и п2. Вот здесь появляются моки,
п.3 — хрупкие тесты, часто вечнозеленые, дают слабые гарантии, их очень дорого писать.
Собтсвенно, поведенческие хрупкие и ломаются при рефакторинге, наприер, результат обеспечили такой же, но иначе, а вот тест сломался. И такое собтсвенно норма для поведенческих тестов на моках
Такой симптом как обилие моков говорит о том, что неверно выбраны уровни тестирования. Т.е. например, функциональные тесты пишутся на уровне юнит-тестов, а через моки определяем признаки поведения. Ну или наооборот — юниты на уровне функциональных, тогда мок дополнительно изолирует выбранный юнит.
Иногда такое необходимо, но только если дизайн кривой настолько, что трудно реализовать п1 или п2. или же имем дело с 3rd party компонентами, когда дизайн изменить нельзя.
На мой взгляд, поведенческие тесты должны использоваться где то на самых высоких уровнях, когда система собрана полностью и нет нужды в моках. Т.е. проверяем реакцию системы на действия пользователя по наличию тех или иных вещей — залогинился, значит ожидаем, что после этого появился персональный контент, который соответствует именно этому логину. Вылогинился — ожидаем, что этот контент исчез из показа.
Здравствуйте, netch80, Вы писали:
I>> не существует методики ни разработки, ни тестирования, которая может дать гарантию отсутствия ошибок
N>Ну почему же. Формальная верификация даёт такую гарантию — где она применима.
Не дает, т.к. в реализации ты можешь чуточку ошибиться, перепутать = и !=, т.е. минорная ошибка, которая просто портит вывод.
I>>Точно так же и в security не сущетсвует способа дать гарантию отсутствия любых уязвимостей.
N>Есть — полная физическая изоляция
Подловил!!!!111
I>>5. приложение покрывает все известные сценарии, см перечень сценариев I>>6. приложение покрывает все критические кейсы, см перечень кейсов
N>И обычно последние два пункта доводят требования до состояния полной нереализуемости.
Здесь ничего странного. Сценариев обычно немного, несколько десятков или сотен. Это все реализуемо относительно небольшими затратами.
Здравствуйте, Poopy Joe, Вы писали:
PJ>Здравствуйте, netch80, Вы писали:
N>>Что TDD это неработающая методика (в чистом виде) — я согласен. Любая практика больше одноразового кода его нарушает. PJ>О чем спор тогда?
О множестве важных деталей и о расстановке принципиальных акцентов.
N>>А вот дальше вы начинаете нести полную чушь, игнорируя реальность и устанавливая некорректные логические связи. Потому что: PJ>"Потому что" тут может быть только один — тебе выдали сертификат носителя истины, но ты забыл его привести. Иначе это просто твое частное мнение.
Ап ту ю. Можете игнорировать, но потом нарвётесь — вспомните.
N>>1. Программные тесты отображают спецификацию к компоненту и позволяют её проверить автоматизированно в любой момент. PJ>Нет, обычно, не отображают. Да, можно выразить спецификацию через тесты.
Вы пропустили, что не "выражают", а именно "отображают". Отображение ограниченно, но искусство программиста — в умении выбрать тесты, которые отражают и типовые, и крайние случаи.
PJ> Так делают через проперти тесты. Проблема с этим подходом только одна: за пределами демонстрационных примеров, типа разворота списка, это сделать достаточно сложно. Во всяком случае в дикой природе встречается в крайне ограниченном виде.
Дикая природа — она разная бывает. Глубинный океан, тайга и саванна различаются принципиально.
Я аналогичным образом разделяю случаи:
1) Алгоритмические задачи. Например, Quicksort. Писать её согласно TDD как-то совсем нереально.
2) Задачи с принципиально неконкретизируемым ответом, но к которым можно применить другие критерии. Например, нейросеть, которая определяет котиков. Она может пропустить 10% котиков тестового набора, если это дозволено.
3) Простые громоздкие задачи со сложным кодом. Например, парсинг HTTP.
4) Простые громоздкие задачи с простым кодом. Например, релеинг запросов бизнес-модели в операторы SQL и обратное преобразование данных.
Общего решения для них не будет. Некоторые подходы работают для всех, но заметно выгибаются.
И вот, кстати, property-based testing пригодно как минимум для 1, 3 и 4.
И я делал такое использование на практике.
Если считать статистически — то и 2.
N>>Таким образом они ещё и работают регрессионными проверками (если что-то сломали позже, запуск тестов это ловит). PJ>Если бы этот подход работал, то в программе бы не было багов. Вообще. Я думаю ты даже сам в эту "чушь" не веришь.
В ваше утверждение — "Если бы этот подход работал, то в программе бы не было багов" — конечно, не верю. Нет причин в него верить.
Тесты, в отличие от формальной верификации, в принципе не могут покрыть всё. У них и задачи такой нет. Задачи тестов:
1. Показать работоспособность для внешнего контроля (заказчик, QA...), который может вообще не интересоваться тем, что в решении есть программная часть и как она устроена.
2. Дать авторам кода средства поиска ошибок, не найденных никакой верификацией (включая визуальную, как peer review). Критически важно из-за принципиального различия методов работы компьютера и человека (например, человек из-за "замыленного глаза" может в упор не видеть ошибку, и не в состоянии получить результат из 100500 уровней #include).
3. Подтвердить корректность внешних постулатов (например, что open() открывает файл согласно пути и ключам, а не звонит в колокольчик).
И вот именно под решение этих задач их и надо продумывать и писать.
PJ> А с чего начинается правильная работа на багом? Правильно, с написания очередного теста для него. Что доказывает неполноту предыдущей спецификации.
Спецификация меняется под задачи. "Неполнота" предыдущей спецификации, а точнее, вообще её отличие (может что-то вообще меняться несовместимо) — норма разработки. Методология должна это учитывать.
Точно так же она должна учитывать и то, что может оказаться, что под новую спецификацию ничего не надо менять. И так бывает.
N>>1) Инверсии — вводится внешняя непрозрачная для логики теста фиксированная модификация, после которой тест может упасть. Проверка заключается в обнаружении планового падения теста. N>>2) Мутации — код компонента или код теста меняется случайным образом и это не должно пройти незамеченным. PJ>Ничего из этого не доказывает ни правильность теста, ни полноту спецификации. Теперь и ты знаешь.
Про полноту спецификации тезис появился только в вашем последнем комментарии. Полная спецификация или нет — вопрос отдельный и к теме тестов напрямую не относящийся, потому что для программиста требуется предельно точное ТЗ. Я не буду рассматривать этот тезис тут.
Правильность теста — точнее, набора тестов — как раз практически подтверждается (слово "доказывается" тут неуместно).
PJ> Не благодари.
Здравствуйте, Ikemefula, Вы писали:
I>>> не существует методики ни разработки, ни тестирования, которая может дать гарантию отсутствия ошибок N>>Ну почему же. Формальная верификация даёт такую гарантию — где она применима. I>Не дает, т.к. в реализации ты можешь чуточку ошибиться, перепутать = и !=, т.е. минорная ошибка, которая просто портит вывод.
Этого не понял — это для какого языка так?
Если описано внешнее требование, то существенные ошибки приведут к нарушению доказательства.
I>>>Точно так же и в security не сущетсвует способа дать гарантию отсутствия любых уязвимостей. N>>Есть — полная физическая изоляция I>Подловил!!!!111
Ага
а если серьёзно — то все уязвимости надо формализовать.
Есть принципиально неустранимые за счёт самого факта доступа.
И отличие проблем "не заткнули известный канал атаки" от "не учли все каналы атаки" принципиально — первое это вопрос корректности кода, а второе это уже не к программистам. Прикладной код не обязан защищаться от Meltdown
I>>>5. приложение покрывает все известные сценарии, см перечень сценариев I>>>6. приложение покрывает все критические кейсы, см перечень кейсов N>>И обычно последние два пункта доводят требования до состояния полной нереализуемости.
I>Здесь ничего странного. Сценариев обычно немного, несколько десятков или сотен. Это все реализуемо относительно небольшими затратами.
Хм, попытался подсчитать сценарии в своём текущем продукте — со всеми вариациями идёт на десятки тысяч.
А всего-то: паркинг против пикапа, транскодинг/трансрейтинг данных, прохождение NAT, темпы реавторизации, ещё десяток факторов...
и разделить, зараза, нельзя толком...
Здравствуйте, netch80, Вы писали:
N>О множестве важных деталей и о расстановке принципиальных акцентов.
И в чем заключаются эти акценты?
N>Ап ту ю. Можете игнорировать, но потом нарвётесь — вспомните.
Нарвусь на что? Я очень переживаю о том считаешь ли ты мои слова чушью, это крайне важно для меня.
N>Вы пропустили, что не "выражают", а именно "отображают". Отображение ограниченно, но искусство программиста — в умении выбрать тесты, которые отражают и типовые, и крайние случаи.
И что это отображение дает?
N>И вот, кстати, property-based testing пригодно как минимум для 1, 3 и 4.
Оно пригодно для всех четырех. В теории. На практике какой процент у тебя таких тестов в общем коде? Вот, то-то и оно.
N>В ваше утверждение — "Если бы этот подход работал, то в программе бы не было багов" — конечно, не верю. Нет причин в него верить.
Я не просил верить в мое утверждение. Я спросил веришь ли ты что в программе нет багов. По определению, если тесты описывают спецификацию и они зеленые, то багов нет. Так ведь? Не?
N>Тесты, в отличие от формальной верификации, в принципе не могут покрыть всё. У них и задачи такой нет. Задачи тестов:
Задача тестов одна, я ее упоминал выше. Отслеживать изменение поведение кода при рефакторинге. Т.е. это автоматизация рутинной работы. Все! Они совершенно ничего не гарантируют и никогда на это нельзя полагаться. Просто несколько облегчает жизнь.
N>1. Показать работоспособность для внешнего контроля (заказчик, QA...), который может вообще не интересоваться тем, что в решении есть программная часть и как она устроена.
Поржал. Сдаешь заказчику программу и на демо показываешь, что все тесты пройдены?
N>3. Подтвердить корректность внешних постулатов (например, что open() открывает файл согласно пути и ключам, а не звонит в колокольчик).
Есть он будет звонить в колокольчик и открывать файл, то твой тест это скорее всего и не заметит.
N>Спецификация меняется под задачи. "Неполнота" предыдущей спецификации, а точнее, вообще её отличие (может что-то вообще меняться несовместимо) — норма разработки. Методология должна это учитывать. N>Точно так же она должна учитывать и то, что может оказаться, что под новую спецификацию ничего не надо менять. И так бывает.
Ниче не понял. Баг это когда ожидается одно, а результат другой. Никакая спецификация тут не меняется.
N>Про полноту спецификации тезис появился только в вашем последнем комментарии.
Потому я отвечал на пост в котором появилось слово спецификация. Внезапно.
N> Полная спецификация или нет — вопрос отдельный и к теме тестов напрямую не относящийся, потому что для программиста требуется предельно точное ТЗ. Я не буду рассматривать этот тезис тут.
Спецификация, в контексте обсуждения, это описание инварианта функции, которую ты тестируешь. Причем тут "предельно точное ТЗ" и где ты такие вообще видел?
N>Разделение на юнит-тесты и интеграционные — терминологическая нелепость.
Не согласен, ибо если для первых полно соотв. библиотек и т.п. , то для второго все индивидуально.
N>"Модуль" может состоять из других модулей хоть в 10 уровней иерархии. N>Есть функциональные тесты разного уровня. Для всех внутренние сущности работают как обычно (ну, с поправкой на то, что, например, логгинг может быть отключен или иначе настроен), а внешние мокаются или эмулируются (разница тут неважна). По отношению ко внутренним составляющим это интеграционные тесты, а по отношению к внешним — юнит-тесты. Ну и зачем?
Даже индивидуальный сервис может мокать, например, фс (io). Почему нет? Речь идет об идеологии юнит-тестов -- максимально
абстрагироваться от внешнего мира и сосредоточится только на bl.
Здравствуйте, Sharov, Вы писали:
N>>Разделение на юнит-тесты и интеграционные — терминологическая нелепость. S>Не согласен, ибо если для первых полно соотв. библиотек и т.п. , то для второго все индивидуально.
Если у тебя есть функция со входом и выходом, то неважно, сколько внутри себя она вызывает других функций — она будет тестироваться как нечто, что получает аргументы и отдаёт результаты.
N>>"Модуль" может состоять из других модулей хоть в 10 уровней иерархии. N>>Есть функциональные тесты разного уровня. Для всех внутренние сущности работают как обычно (ну, с поправкой на то, что, например, логгинг может быть отключен или иначе настроен), а внешние мокаются или эмулируются (разница тут неважна). По отношению ко внутренним составляющим это интеграционные тесты, а по отношению к внешним — юнит-тесты. Ну и зачем?
S>Даже индивидуальный сервис может мокать, например, фс (io). Почему нет? Речь идет об идеологии юнит-тестов -- максимально S>абстрагироваться от внешнего мира и сосредоточится только на bl.
Ну а интеграционные, что, не абстрагируются от внешнего мира?
Или речь про проведение границы между "чистыми" и "нечистыми" функциями?
Здравствуйте, netch80, Вы писали:
N>Если у тебя есть функция со входом и выходом, то неважно, сколько внутри себя она вызывает других функций — она будет тестироваться как нечто, что получает аргументы и отдаёт результаты.
Это таки важно, если идет обращение к другим модулям\сервисам. Иной раз задолбаешься все поднимать. Замокал и тестируй себе.
S>>Даже индивидуальный сервис может мокать, например, фс (io). Почему нет? Речь идет об идеологии юнит-тестов -- максимально S>>абстрагироваться от внешнего мира и сосредоточится только на bl.
N>Ну а интеграционные, что, не абстрагируются от внешнего мира?
Ну это почти боевая эксплуатация, т.е. как реальный пользователь будет взаимодействовать с системой.
N>Или речь про проведение границы между "чистыми" и "нечистыми" функциями?
Здравствуйте, Sharov, Вы писали:
N>>Ну а интеграционные, что, не абстрагируются от внешнего мира? S>Ну это почти боевая эксплуатация, т.е. как реальный пользователь будет взаимодействовать с системой. N>>Или речь про проведение границы между "чистыми" и "нечистыми" функциями? S>В некотором роде да, речь про изоляцию.
Как-то всё это абстрактно. Вот у меня есть:
1. Transport layer.
2. Transaction layer, использует transport layer.
3. Dialog layer, использует transaction layer.
Остановимся на этом (там ещё уровня 4, но не усложняем).
Transport layer незамоканный отправляет в сеть и принимает; замоканный зовёт нужные коллбэки.
Уровень транзакций незамоканный общается с транспортным, замоканный дёргает вызовы некоего мока.
Ну и с третьим точно так же.
Если я тестирую диалоговый уровень — что например по получению "200 OK" произошёл переход состояния объекта Dialog из Trying или Early в Confirmed, и посылаю это как вызов processResponse() от транзакционного модуля, это юнит-тест?
А если я сделаю то же самое, сэмулировав сетевой ответ от транспорта (тогда у транзакционного его processIncoming() опознает ответ, заматчит транзакцию, найдёт коллбэк диалога в её состоянии и вызовет его), это ещё юнит-тест или уже интеграционный?
А если я реально пришлю UDP пакет в транспорт, это уже интеграционный тест или ещё нет?
А если это будет TLS поверх TCP (расшифровка которого делается в third-party в лице OpenSSL)?
С моей точки зрения, это всё функциональные тесты, и пофиг, что из них считать "юнитами". А как в остальном мире?
Здравствуйте, netch80, Вы писали:
PJ>>Задача тестов одна, я ее упоминал выше. Отслеживать изменение поведение кода при рефакторинге. N>Если ты используешь тесты ровно для этого — это твои личные ограничения.
А для чего еще нужно использовать юнит-тесты кроме как "локально" корректности кода? Ловить
проблемы при рефакторинге или изменении BL.
N>Transport layer незамоканный отправляет в сеть и принимает; замоканный зовёт нужные коллбэки. N>Уровень транзакций незамоканный общается с транспортным, замоканный дёргает вызовы некоего мока. N>Ну и с третьим точно так же. N>Если я тестирую диалоговый уровень — что например по получению "200 OK" произошёл переход состояния объекта Dialog из Trying или Early в Confirmed, и посылаю это как вызов processResponse() от транзакционного модуля, это юнит-тест?
Да.
N>А если я сделаю то же самое, сэмулировав сетевой ответ от транспорта (тогда у транзакционного его processIncoming() опознает ответ, заматчит транзакцию, найдёт коллбэк диалога в её состоянии и вызовет его), это ещё юнит-тест или уже интеграционный?
Я бы сказал да. Ну точно не интеграционный.
N>А если я реально пришлю UDP пакет в транспорт, это уже интеграционный тест или ещё нет?
Интеграционный тест. Проверяем все целиком, т.е. вполне реальное взаимодействие. Т.е. если провели
с сетевой картой, то тест упадет.
N>А если это будет TLS поверх TCP (расшифровка которого делается в third-party в лице OpenSSL)?
Зависит от, см. выше. Если хоть что-то замокано, то не интеграционный точно.
N>С моей точки зрения, это всё функциональные тесты, и пофиг, что из них считать "юнитами". А как в остальном мире?
Здравствуйте, Poopy Joe, Вы писали:
N>>Вот после этого можно говорить — не абсолютно, но с практически достаточной уверенностью — про отсутствие багов. PJ>И че хоть раз такое происходило? Ну, только честно.
Постоянно происходит, честно.
Например, QA в очередном релизе отловил 20 багов; у кастомеров сработало ещё 10; перед этим запуском в Jenkins было поймано и исправлено 300-400.
Перед этим ещё 100 (народ достаточно ленив) поймано самими программистами, в варианте "вот я наверно это сломаю... пойду запущу сразу, не дожидаясь получасового прогона всех тестов".
Цифры меняются, соотношение примерно похоже на это.
Ну а так как цена отлова бага на стадии CI в десятки раз меньше такого же на кастомере (не считая потерь самого кастомера), то можно было бы и 95% времени тратить на тесты. Это уже не получается — не организуешь людей на это.
N>>Ну вот я выше и описал. Разница между "ничего не гарантируют" и "статистически гарантируют поиск >90% ошибок", по-твоему, важна или нет? PJ>Нет, разумеется. Гарантия понятия бинарное, она либо есть, либо ее нет. И нет, тесты этого не гарантируют. Все что гарантируют тесты, это если у тебя измениться поведение функции которую проверяет тест, при условии, что тест проверяет конкретный случай, то он это покажет.
Ну вот пока ты будешь так думать, будешь предельно непрактичен.
И я не зря "подпёр" полезность тестов условием верификации кода.
N>>И да, в это я верю. Как-то практика показывает, что именно так и оно и работает PJ>В стране с единорогами?
Реальные проекты, реальные люди со всеми их проблемами.
Просто систему наладили и она кое-как, подпрыгивая на ухабах, но постоянно движется вперёд.
Единорогов не впрягали, за неимением таковых.
N>>Конечно, нет. Может, у тебя один тест, который проверяет, как main() разбирает аргументы, и он зелёный PJ>Во, ты начинаешь что-то подозревать. Прикол в том, что это ничем не отличается ни от 1000, ни от 10000. N>>1) Разумность самих тестов (метода, набора тестовых данных), с точки зрения нахождения проблем реализации согласно задаче и выбранному методу. PJ>И как ты проверяешь разумность?
По каждому случаю отдельно.
Вот пример (не мой): у процессора нет операции умножения, надо её сэмулировать. Делается вариант 16*16->16 с откидыванием старшей части. Знаем, что будет какой-то цикл по битам.
Добавляем тесты: 0*0 -> 0, 1*0 -> 0, 1*1 -> 1, 2*0 -> 0, 0*2 -> 0, 2*2 -> 4, 2*-2 -> -4, -2*2 -> -4, 2*2 -> 4.
Ещё парочку базовых, типа 137*73 -> 10001.
На переполнение: 256*256 -> 0, 257*257 -> 513, -32768*3 -> -32768...
Пара десятков таких тестов покроет и базовую функциональность, и маргинальные случаи, с запасом на все типовые алгоритмы.
N>>2) Верификация кода (хотя бы визуальная) на то, что реализован действительно нужный подход (а не поставлен, грубо говоря, большой if на конкретные тестируемые случаи). PJ>Жесть какая...
Что удивляет-то? Никогда peer review не проходил? Ну, всё впереди.
N>>3) Достаточное покрытие нужного-по-ТЗ кода тестами (несмотря на всю условность этого понятия). PJ>Достаточное это какое?
100% хотя бы одним тестом каждого куска кода основного пути выполнения.
Не считаются те, которые вызываются плохо предсказуемыми внешними условиями, хотя и их можно на следующем круге замокать.
N>>4) Доверие среде и библиотекам. PJ>А нафига тогда все предыдущие?
Ну мало ли. Вдруг в следующей версии починят? )
N>>Были, где, грубо говоря, 90%. Сейчас крайне мало — но это потому, что ресурсов нет. А так я бы и сейчас добавил переменных. PJ>Охотно верю, был демо проект, где 90% и реальный код, где их почти нет. Я ровно об этом.
Это у тебя демо, а у меня был полностью реальный.
N>>Если ты используешь тесты ровно для этого — это твои личные ограничения. PJ>Увы, не мои. Это ограничение самой методики. Вот честно, хотелось бы иметь волшебную технологию уровня "компилируется — в продакшн"
Ограничения у методики есть, но сильно дальше, чем ты их видишь.
N>>А почему ты в этом рассмотрении предполагаешь только внутренние кодовые тесты? PJ>Потому что речь о ТDD.
Нет, не только.
PJ> Впрочем, заказчика вообще никакие тесты не интересуют. Я, по-крайней мере, таких не видел.
Ну я видел, и работал с. И ты не учитываешь внутреннего заказчика в продукте.
N>>Это ловится на других уровнях и другими методами. PJ>Какими?
Да хоть ручной проверкой. Это уже не наша задача.
N>>А кто только что писал про предыдущую спецификацию? Сам уже не помнишь, что писал? PJ>Я вообще не понял, что ТЫ написал. Я либо впервые использовал слово спецификация, либо использовал его до этого. Оба утверждения твои и оба они не могут быть верными одновременно.
Я про предыдущую спецификацию вроде не писал первый.
N>>OK. Представим себе, что "спецификация" это "полное и точное ТЗ", и пойдём дальше. Так откуда взялась предыдущая спецификация? PJ>I'm lost. Полное и точное ТЗ, это функциональные требования к системе, это функциональные тесты, в лучшем случае. PJ>Спецификация о которой идет речь это спецификация на отдельные куски кода, которые ты покрываешь тестами. Представим, что теплое это мягкое и пойдем дальше.
Ну у тебя почему-то ТЗ это сверху, а спецификация это снизу. Я не вижу причин так делить.
N>>Сарказм понят, но не оценён. Нарвёшься на то, что будешь отказываться от доступных средств из-за гордыни. PJ>От каких доступных средств я отказываюсь? От тестов? Это ты сам придумал. PJ>От построения из них карго-культа? Так это ты нарвешься, думая, что они тебе чего-то там гарантируют.
Я получаю с них реальную пользу — баги ловятся задолго до попадания к кастомеру. А ты можешь продолжать искать и требовать воздушные замки.
Здравствуйте, netch80, Вы писали:
N>Постоянно происходит, честно.
Как это сочетается с следующим предложением? N>Например, QA в очередном релизе отловил 20 багов; у кастомеров сработало ещё 10;
N> перед этим запуском в Jenkins было поймано и исправлено 300-400. Вам надо ваш процесс переименовать с разработки через тестирование, на разработку через багфиксы.
N>Цифры меняются, соотношение примерно похоже на это.
Ну, я хотя бы понял, что у вас называется "отсутствием багов". Оказалось, что просто общаемся из разных планов бытия.
N>Ну вот пока ты будешь так думать, будешь предельно непрактичен.
Возможно, зато у нас кастомеры не ловят в "безбаговых" продуктах по 10 багов + еще хрен знает сколько не пойманых.
N>Единорогов не впрягали, за неимением таковых.
Угу, у вас вместо них кастомеры.
N>Что удивляет-то? Никогда peer review не проходил? Ну, всё впереди.
Ты ща начал размером опыта давить что ли? Не стоит.
Я никогда не видел, чтобы ревью чего-то доказывало. Особенно уровня "у тебя тут if не хватает".
N>100% хотя бы одним тестом каждого куска кода основного пути выполнения.
Понятно, тесты ради тестов, покрытие, ради покрытия.
N>Не считаются те, которые вызываются плохо предсказуемыми внешними условиями, хотя и их можно на следующем круге замокать.
Ты хоть и не просил, но бесплатный совет: когда ты видишь, что тебя надо что-то мокать — ты видишь у себя неправильный дизайн.
N>Нет, не только.
Ну может ты еще о чем-то своем, но я говорил о разработке через тестирование.
N>Ну я видел, и работал с. И ты не учитываешь внутреннего заказчика в продукте.
Нет конечно, им точно так же похрен на твои тесты.
N>Да хоть ручной проверкой. Это уже не наша задача.
Что не твоя задача? Качество? Тогда зачем париться с тестами?
N>Я про предыдущую спецификацию вроде не писал первый.
Слово спецификация впервые употребил ты. http://rsdn.org/forum/flame.comp/8032039.1
Если ты тестами описываешь спецификацию, то новый тест спецификацию расширяет/меняет, поэтому старая она становится предыдущейю. Не бог весть какая логика. Дальше я твою мысль не понимаю вообще.
N>Ну у тебя почему-то ТЗ это сверху, а спецификация это снизу. Я не вижу причин так делить.
Ты опять чего-то выдумываешь. Я не употреблял слова верх или низ.
N>Я получаю с них реальную пользу — баги ловятся задолго до попадания к кастомеру. А ты можешь продолжать искать и требовать воздушные замки.
Ага, я вижу.
Здравствуйте, netch80, Вы писали:
N>Это очень прикольно, учитывая, что 1) я никогда не говорил, что ведём "разработку через тестирование", 2) никогда не утверждал отсутствие багов как результат применения тестов.
Для того, чтобы с достаточной уверенностью доверять результатам тестов, нужно:
1) Разумность самих тестов (метода, набора тестовых данных), с точки зрения нахождения проблем реализации согласно задаче и выбранному методу.
2) Верификация кода (хотя бы визуальная) на то, что реализован действительно нужный подход (а не поставлен, грубо говоря, большой if на конкретные тестируемые случаи).
3) Достаточное покрытие нужного-по-ТЗ кода тестами (несмотря на всю условность этого понятия).
4) Доверие среде и библиотекам.
Вот после этого можно говорить — не абсолютно, но с практически достаточной уверенностью — про отсутствие багов.
Погоди, перед тем как уйдешь, позови, пожалуйста, того, кто писал эту цитату с твоего аккаунта.
Здравствуйте, Poopy Joe, Вы писали:
N>>Это очень прикольно, учитывая, что 1) я никогда не говорил, что ведём "разработку через тестирование", 2) никогда не утверждал отсутствие багов как результат применения тестов.
PJ>
PJ>Для того, чтобы с достаточной уверенностью доверять результатам тестов, нужно:
PJ>1) Разумность самих тестов (метода, набора тестовых данных), с точки зрения нахождения проблем реализации согласно задаче и выбранному методу.
PJ>2) Верификация кода (хотя бы визуальная) на то, что реализован действительно нужный подход (а не поставлен, грубо говоря, большой if на конкретные тестируемые случаи).
PJ>3) Достаточное покрытие нужного-по-ТЗ кода тестами (несмотря на всю условность этого понятия).
PJ>4) Доверие среде и библиотекам.
PJ>Вот после этого можно говорить — не абсолютно, но с практически достаточной уверенностью — про отсутствие багов.
PJ>Погоди, перед тем как уйдешь, позови, пожалуйста, того, кто писал эту цитату с твоего аккаунта.
"С практически достаточной уверенностью". Но не абсолютно.
Когда поймёшь разницу и расскажешь про это — продолжим.
Здравствуйте, netch80, Вы писали:
N>Этого не понял — это для какого языка так? N>Если описано внешнее требование, то существенные ошибки приведут к нарушению доказательства.
Покажи пример, а то мне непонятно.
I>>Здесь ничего странного. Сценариев обычно немного, несколько десятков или сотен. Это все реализуемо относительно небольшими затратами.
N>Хм, попытался подсчитать сценарии в своём текущем продукте — со всеми вариациями идёт на десятки тысяч. N>А всего-то: паркинг против пикапа, транскодинг/трансрейтинг данных, прохождение NAT, темпы реавторизации, ещё десяток факторов... N>и разделить, зараза, нельзя толком...
Таких проектов нынче капля в море, к сожалению. Типичный проект это гораздо более простые вещи.
Здравствуйте, Poopy Joe, Вы писали:
PJ>Почему нельзя воспользоваться требованиями, методиками, подходами и далее по списку, в отношении решения, а не теста? Этого либо достаточно, либо еще нужен тест для теста для теста...
Кто сказал, что нельзя? Пользуйся сколько угодно. Только это не отменяет тесты, нисколько. А раз так, то все это нужно применять и к тестам.
Тест теста в большинстве случаев заменяется на верификацию — посмотрели, прошли чеклист, закрыли. С кодом самого приложения тоже многие вещи решаются верификацией.
PJ>Для того, чтобы с достаточной уверенностью доверять результатам тестов, нужно:
PJ>1) Разумность самих тестов (метода, набора тестовых данных), с точки зрения нахождения проблем реализации согласно задаче и выбранному методу.
PJ>2) Верификация кода (хотя бы визуальная) на то, что реализован действительно нужный подход (а не поставлен, грубо говоря, большой if на конкретные тестируемые случаи).
PJ>3) Достаточное покрытие нужного-по-ТЗ кода тестами (несмотря на всю условность этого понятия).
PJ>4) Доверие среде и библиотекам.
PJ>Вот после этого можно говорить — не абсолютно, но с практически достаточной уверенностью — про отсутствие багов.
PJ>Погоди, перед тем как уйдешь, позови, пожалуйста, того, кто писал эту цитату с твоего аккаунта.
Здравствуйте, Poopy Joe, Вы писали:
N>>"С практически достаточной уверенностью". Но не абсолютно.
PJ>В системе, где должно быть багов 0, найдено 30. Я бы сказал это крайне низкий порог для любого уровня уверенности.
"должно быть 0 багов" — это неадекватное ожидание. Никто и никогда, ни при каких условиях, не может гарантировать выполнение этого требования.
То есть, нет способа различить две ситуации — "нет багов" и "мы не знаем, есть ли новые неизвестные баги".
Здравствуйте, Ikemefula, Вы писали:
I>То есть, нет способа различить две ситуации — "нет багов" и "мы не знаем, есть ли неизвестные баги".
Ну почему же, есть же соотв. инструменты верификации. Или, например, у нас КА с большим кол-вом состояний и т.п.
И тем не менее можно для каждого набора входных данных проверить корректность состояния и быть увереным, что багов
нет. Но это только для простых случаев. Т.е. в теории ситуация "нет багов" возможна, на практике -- едва ли.
Здравствуйте, Sharov, Вы писали:
I>>То есть, нет способа различить две ситуации — "нет багов" и "мы не знаем, есть ли неизвестные баги".
S>Ну почему же, есть же соотв. инструменты верификации. Или, например, у нас КА с большим кол-вом состояний и т.п.
Каким образом понять, что некто воспользовался этим инструментом, а не накида КА на глазок?
Каким образом понять, что интеграция этого КА сделана как положено, а не просто затычкой вида "и так сойдет" ?
Здравствуйте, Sharov, Вы писали:
S>>>Ну почему же, есть же соотв. инструменты верификации. Или, например, у нас КА с большим кол-вом состояний и т.п. I>>Каким образом понять, что некто воспользовался этим инструментом, а не накида КА на глазок?
S>1)КА реализуется программистом, верфицируется кодом. S>2)Ответ на вопрос выше -- соотв. процессом.
Ты опредились, код или процесс. Если процесс, то он всегда двигается людьми, т.е. некто должен посмотреть глазом, что все идет путём.
I>>Каким образом понять, что интеграция этого КА сделана как положено, а не просто затычкой вида "и так сойдет" ?
S>Соотв. процессом.
Именно. Ибо код принципиально не может решить задачу "кто будет сторожить сторожа"
S>Под процессом имеется в виду соотв. инструменты, системы сборки, тесты, code review и, вероятно, много чего еще. S>На глазок в подобным проектах никто ничего не делает.
Делают, только такие попытки не проходят верификацию.
S>Но речь о том, что софт вполне себе можно верифицировать.
Ок. начинаем сначала — кто проверит, что КА ты накидал не от балды, а руководствовался внятным подходом?
S>А ошибки будут либо на уровне тз (метры с дюймами попутали, читал где-то про какой-то луноход или что-то в этом роде:
А еще бывают ошибки, когда некто струячит в духе "и так сойдет"
И все это покрывает вечно-зелеными тестами.
Здравствуйте, Ikemefula, Вы писали:
S>>1)КА реализуется программистом, верфицируется кодом. S>>2)Ответ на вопрос выше -- соотв. процессом. I>Ты опредились, код или процесс. Если процесс, то он всегда двигается людьми, т.е. некто должен посмотреть глазом, что все идет путём.
Так, наверное, почти любой процесс можно автоматизировать.
S>>Под процессом имеется в виду соотв. инструменты, системы сборки, тесты, code review и, вероятно, много чего еще. S>>На глазок в подобным проектах никто ничего не делает. I>Делают, только такие попытки не проходят верификацию.
Ну и хорошо.
S>>Но речь о том, что софт вполне себе можно верифицировать. I>Ок. начинаем сначала — кто проверит, что КА ты накидал не от балды, а руководствовался внятным подходом?
Другой код. Который проверяет вход и выход. Как пример.
S>>А ошибки будут либо на уровне тз (метры с дюймами попутали, читал где-то про какой-то луноход или что-то в этом роде: I>А еще бывают ошибки, когда некто струячит в духе "и так сойдет" I>И все это покрывает вечно-зелеными тестами.
Докопаться можно до чего угодно, было бы желание. В проектах о которых я говорил, надеюсь, подобного нет. Там все и все
под контролем. Это сложно, но разрабатывают они на относительно простых языках без всякой многопоточности. Это легче.
I>Какой код проверит, что твои тесты вечнозелёные?
К чему этот вопрос, заданный выше не один раз в той или иной форме. И да, в коде верификатора тоже могут быть ошибки.
Но я повторю, что написать корректную программу вполне не сложно. Написать большую и сложную корректную программу очень и очень
сложно.
Здравствуйте, Sharov, Вы писали:
I>>Ты опредились, код или процесс. Если процесс, то он всегда двигается людьми, т.е. некто должен посмотреть глазом, что все идет путём.
S>Так, наверное, почти любой процесс можно автоматизировать.
Ок, покажи, как ты автоматизируешь проверку тестов на вечнозеленость.
S>>>Но речь о том, что софт вполне себе можно верифицировать. I>>Ок. начинаем сначала — кто проверит, что КА ты накидал не от балды, а руководствовался внятным подходом?
S>Другой код. Который проверяет вход и выход. Как пример.
Никакой гарантии. Тот, кто пишет абы как, и этот другой код тоже напишет абы как.
S>Докопаться можно до чего угодно, было бы желание. В проектах о которых я говорил, надеюсь, подобного нет. Там все и все S>под контролем. Это сложно, но разрабатывают они на относительно простых языках без всякой многопоточности. Это легче.
Вопрос в том, как именно этот контроль реализован.
I>>Какой код проверит, что твои тесты вечнозелёные?
S>К чему этот вопрос, заданный выше не один раз в той или иной форме.
А ты продолжаешь утверждать, что это можно как то автоматизировать. Вот мне и интересно, что это за чудо.
Скажем, до сих пор никто не может автоматизировать поиск новых багов. Кое что можно находить автоматически. А вот полностью заменить поиск новых, неизвестных багов еще пока никто не научился.
И верифицировать произвольный код тоже никто не научился автоматически.
S>>Так, наверное, почти любой процесс можно автоматизировать. I>Ок, покажи, как ты автоматизируешь проверку тестов на вечнозеленость.
Что такое вечнозеленость? Проверить, прошел тест или нет, не то?
S>>Другой код. Который проверяет вход и выход. Как пример. I>Никакой гарантии. Тот, кто пишет абы как, и этот другой код тоже напишет абы как.
А кто сказал, что это один и тот же человек? Скорее всего это всегда будут разные люди. Человек, написавший
какой-нибудь верфикатор, и человек, написавшей прикладное ПО, скорее всего всегда будут разными людьми.
S>>Докопаться можно до чего угодно, было бы желание. В проектах о которых я говорил, надеюсь, подобного нет. Там все и все S>>под контролем. Это сложно, но разрабатывают они на относительно простых языках без всякой многопоточности. Это легче. I>Вопрос в том, как именно этот контроль реализован.
Ну посмотрите или почитайте как в том же NASA процесс организован. Я как-то читал и понял, что пишут они на каком-то
Си подобном диалекте, куча тестов и др. инструментов для валидации корректности кода.
S>>К чему этот вопрос, заданный выше не один раз в той или иной форме. I>А ты продолжаешь утверждать, что это можно как то автоматизировать. Вот мне и интересно, что это за чудо.
Я же не категорично утверждал, верно. Ну вот как-то всяческие спутники и прочие марсоходы и луноходы выполняю свою
миссию. Как-то все это делается, и большая вероятность, что не через ручной труд или с самым его минимумом.
I>Скажем, до сих пор никто не может автоматизировать поиск новых багов. Кое что можно находить автоматически. А вот полностью заменить поиск новых, неизвестных багов еще пока никто не научился. I>И верифицировать произвольный код тоже никто не научился автоматически.
Ну разумеется, если для верфикации нужно писать на спец. диалектах, а не на, скажем, С99. Там просто так память не выделишь.
Вы на многие свои вопросы можете найти ответы банальным гуглежом по практикам НАСА или как крупные компании повышают качество своего кода.
Здравствуйте, Ikemefula, Вы писали:
I>>>Ок, покажи, как ты автоматизируешь проверку тестов на вечнозеленость. S>>Что такое вечнозеленость? Проверить, прошел тест или нет, не то? I>Вечнозеленый тест, это который никогда не фейлится, что бы ни ломалось в коде. I>Тесты зеленые — компоненты не работают, степень покрытия — 99% строк в коде.
Ну значит требовать 100% покрытия.
S>>Ну разумеется, если для верфикации нужно писать на спец. диалектах, а не на, скажем, С99. Там просто так память не выделишь. I> А что, диалект как то решает проблему "и так сойдёт" ?
"И так сойдет" обязательный code review, тесты и замеры производительности могут выявить. Но степень свободы в таких
диалектах явно будет меньше, т.е. возможности налажать и выстрелить в ногу будет меньше.
В целом хороший вопрос, а как борются с не оптимально написанным кодом, который корректно решает проблему?
Замеры, code review. Что тут еще можно придумать? Наверное в компаниях типа NASA с мотивацией сотрудников все в порядке,
т.е. сотрудники не позволяют себе "и так сойдет", а делают все оптимально возможным образом +
минимум аджайла, когда нужно было вчера и т.п. подобные организационные вещи. Т.е. личные кач-ва сотрудников + соотв. процессы.
А как иначе?
Хотя вот Boeing это не очень помогло, но там видимо был лютый бардак в процессах.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Sharov, Вы писали:
S>>Ну значит требовать 100% покрытия. I>Это или невозможно, вообще говоря, в большинстве случаев, или же этот 1% будет таким же как и остальные 99%.
А как такое возможно в случае 100%? Это значит что результат работы ф-ий банально не проверялся, код вроде бы не падает,
а работает не корректно. Это либо намеренно, либо . Если такое обнаруживается -- 100% покрытие, а ничего не работает --
то тут только серьезное разбирательство поможет и разговор с программистами.
S>>А как иначе? I>Не стоит вообще не пытаться решать обозначеную проблему ни автоматизацией, ни кодом, ни покрытием, ни тестами-тестов. I>Можно, например, внедрять код-ревью в котором верификация решения как обязательный чек поинт. I>Собственно, почти всегда за такими вот тестами кроется и код, который писался ровно с таким же отношением к работе. I>Людей замеченых в написании подобных решений отстранять, если не хотят работать иначе.
Как вариант, но лучше больше инструментария задействовать чем только cr.
Здравствуйте, Sharov, Вы писали:
I>>Это или невозможно, вообще говоря, в большинстве случаев, или же этот 1% будет таким же как и остальные 99%.
S>А как такое возможно в случае 100%?
Элементарно — тесты написаны кое как.
Более того, когда менеджеры спускают требование 100% именно так и случается — вечнозеленые тесты повсюду, абы достичь этих процентов.
По этой причине никогде не нужно задирать планку выше разумного.
S>>За исключением тех случаев, когда эти 100% действительно нужны. I>Это не добавляет качества, а количество работы удесятеряет. Стоит покрывать не строчки кода, а ключевые кейсы. Здесь проценты не зафиксируешь, зато эффекта будет гораздо больше. I>Нужно понимать, что 100% это всего лишь про строчки, а не ветвления.
А разве в 100% ветвления не входят?
I>То есть, покрыв 100% строчек можно нисколечко не приблизиться к покрытию основных кейсов. I>Считать ветвления еще не научились, а простой подсчет говорит о том, что покрытие ветвлений требует астрономическое количество тестов.
По-моему, научились. Там этих метрих для покрытия кода чуть ли не 3, и одна из них про ветвления.
I>Зато покрытие основных кейсов вполне может дать покрытие 80% строчек. Остальное покроется тестами верхнего уровня, тестами на стейджинге и тд.
Я не против, но такое ощущение что путаете разработку сайта или какого продукта или сервиса по аджайл с разработкой
марсохода у НАСА. Это совершенно два разных мира, и если где-то 100% действительно не нужно ибо долго и дорого, а надо фичи
пилить, то где-то без 100% покрытия шагу не сделают. О чем тут спор тогда?
Здравствуйте, Sharov, Вы писали:
I>>Это не добавляет качества, а количество работы удесятеряет. Стоит покрывать не строчки кода, а ключевые кейсы. Здесь проценты не зафиксируешь, зато эффекта будет гораздо больше. I>>Нужно понимать, что 100% это всего лишь про строчки, а не ветвления.
S>А разве в 100% ветвления не входят?
Очевидно, нет — для 100% ветвлений нужно астрономическое число тестом. См. Искусство тестирования, Гленфорд Майерс
I>>Считать ветвления еще не научились, а простой подсчет говорит о том, что покрытие ветвлений требует астрономическое количество тестов.
S>По-моему, научились. Там этих метрих для покрытия кода чуть ли не 3, и одна из них про ветвления.
См. книгу выше. S>Я не против, но такое ощущение что путаете разработку сайта или какого продукта или сервиса по аджайл с разработкой S>марсохода у НАСА. Это совершенно два разных мира, и если где-то 100% действительно не нужно ибо долго и дорого, а надо фичи S>пилить, то где-то без 100% покрытия шагу не сделают. О чем тут спор тогда?
А не надо сюда наса тянуть, это единичные проекты. И даже там нет смысла гнаться за строчками и прочими глупыми КПИ. Внятный код-ревью экономит годы разработки даже в наса.
Еще раз
— 100% строчек могут нисколько не покрыть кейсы, компоненты могут валиться, а все тесты будут зелеными
— 100% ветвлений это астрономическое число тестов
Именно по этой причине используются разные методы одновременно.
The cyclomatic complexity of a section of source code is the maximum number of linearly independent paths within it—where "linearly independent" means that each path has at least one edge that is not in one of the other paths.
То есть, это не все пути/ветвления, а только некоторая часть. Более того, нас интересуют большей частью скрытые ветвления, который в силу отсутствия ссылочной прозрачности выявить не получается.
Отсюда понятно, почему бОльшая часть инструментов про покрытие оперирует строчками.
I>The cyclomatic complexity of a section of source code is the maximum number of linearly independent paths within it—where "linearly independent" means that each path has at least one edge that is not in one of the other paths.
I>То есть, это не все пути/ветвления, а только некоторая часть. Более того, нас интересуют большей частью скрытые ветвления, который в силу отсутствия ссылочной прозрачности выявить не получается. I>Отсюда понятно, почему бОльшая часть инструментов про покрытие оперирует строчками.
Ну и в догонку:
The essence of this observation is that larger programs tend to be more complex and to have more defects. Reducing the cyclomatic complexity of code is not proven to reduce the number of errors or bugs in that code.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
. Если такое обнаруживается -- 100% покрытие, а ничего не работает --