Здравствуйте, ·, Вы писали:
P>>Чем ваши acceptance и smoke отличаются от e2e ?
·>acceptance и smoke — подвиды e2e. Первые запускаются до деплоя, вторые запускаются сразу после. Если smoke-тест падает — делается откат к предыдущей версии.
Итого — e2e у вас есть.
P>>Тесты напрямую не влияют на качество — это просто индикаторы симптомов.
P>>Более того, если тесты зеленые, это говорит всего лишь "не обнаружили", а что там на самом деле с софтиной — а хрен его знает, если у вас нет 1-4
P>>Хотите повышать качество — нужно проектировать, кодить больше, лучше, помогать другим, документировать, итд, итд.
·>Угу. Вот только все эти усилия помножатся на ноль без авто-тестов.
Помножатся. Только без 1-4 тесты вообще смысла не имеют. Попробуйте писать тесты до появления треботваний, результаты пишите сюда.
P>>·>У тебя память как у рыбки. Цитирую:
P>>·>P>>·>·>потенциально может быть null — ты не дождёшься окончания.
P>>·>
P>>Я шота не понял ваш аргумент.
·>В смысле ты не понял что ты хотел сказать своей цитатой? Ничем помочь не могу.
Это ваша цитата
http://rsdn.org/forum/design/8701337.1Автор: ·
Дата: 29.02.24
Вот мы и узнали, у кого память как у рыбки. И уже в который раз
P>>·>P>>·>...в составе юнит-тестов, где нас интересуют подробности
P>>·>— а что если в колонке пусто
P>>·>
P>>Непонятный аргумент. Подробнее никак?
·>Аргумент чего? Это твоя цитата. Что она значит — разбирайся сам.
"а что если в колонке пусто" — вот это вроде бы уже выясняли. Вам еще хочется пройтись по кругу?
P>>Это значит, что у вас простой кейс — для всего дадена спека. Что делать будете, кода результат вашей работы это и спека, и софт по ней?
·>Ещё проще.
Нет, не проще. В этом случае вам нужно отрабатывать не один вариант, который навязывается спекой, а несколько, и выбирать из них оптимальный для предполагаемых потребителей.
Накидали вы один, сделали демо — а вам сказали, это не годится. Вы другой вариант — и тот забраковали. И так до тех пор, пока не выдадите более-менее внятный. А походу дела подтягиваете спецификацию
P>>Вы зачем то снова пустились в фантазирование. Юзер у вас что, на бакенде сидит? Нет ведь. Он в каком то клиентском приложении. Вот там и ищите фоновый процессинг.
·>В смысле фоновой процессинг в 3rd party внешней системе? Ну тогда это их проблема, поведение нашего api задокументировано.
Т.е. вы не понимаете, что фронтенд, мобайл, десктоп может быть частью вашей системы?
P>>В проде указали 30 минут, а из за мержа конфигов у вас стало 300, например, потому что это дефолтное значение. Это снова пример проблемы которая идет мимо ваших моков.
·>Дифф конфигов прода и теста покажет отстутствие параметра.
Как то слишком категорично. Думаете вы один умеете конфиги сравнивать?
Посмотрите в коде — где у вас дефолтные значения для параметров по умолчанию?
У вас что, все 100500 возможных констант исключительно в конфигах?
Дефолтные значения могут подкидываться даже либами, если вы забудете подкинуть значение.
P>>·>Забитость очереди — это красный сигнал в мониторинге.
P>>Именно что в мониторинге, а не в ваших тестах на моках. И только под нагрузкой.
·>Угу, и?
Мы только что выяснили, что моками вы никаких гарантий дать не можете — все равно придется ждать деплоя на прод и смотреть в мониторинг когда нагрузка стала той самой
P>>Например, разработчик кое что подтюнил в коде, что бы легче было воспроизвести другую багу. И забыл это убрать.
·>Треш какой-то у вас творится.
Вот снова вы ни о чем.
P>>Вы до сих пор название топика не вкурили? dependency rejection это целиком про дизайн.
·>Это вроде давно обсудили. Ты потом переключился на моки.
Это все в контексте дизайна который определяется тестами. Написали под моки — значит пропихивать зависимости так, а не иначе. И всё, приплыли.
P>>Построили дизайн под моки — естественно, кроме моков ничего и не будет.
·>Нет никакого дизайна под моки. Есть внешние системы — будут моки.
У вас именно так — вы считаете моки единственным инструментом для работы с зависимостями.
P>>Это всё мимо. Экземпляр UI приложения это штука глобальная, вне езависимости от того, где вы держите переменную app — глобально или в стеке функции main или хоть вообще нигде. Это ж не сервер, где на запрос можно поднимать хоть целый процесс.
·>Мде. Видимо вообще вы с Sinclair не вдупляете что такое глобальные переменные. Поэтому и используете, не видя разницы.
Скорее это вы почему то не понимаете, что мир не сводится к вашему проекту.
Подозреваю, вы и под глобальными переменными вы подразумеваете чтото другое.
P>>Да, вы эту сказку много раз повторяли — у вас мониторинг любую даже гипотетически возможную проблему обнаруживает сразу.
·>Это ты опять врёшь, я такое не говорил. А у вас тестинг занимается обнаружением любых гипотетических проблем, да?
Очевидно, что нет. Только зафиксированых на момент написания теста. И этих проблем он обнаруживает на два порядка больше мониторинга.
P>>Вы что, повсюду в бизнес-логике пишете "if user.isTest() " ? Очень вряд ли. Интеграция для тестового юзера и реального будет та же самая. Соответственно, обнаруженные проблемы практически наверняка будут играть и для тестовых юзеров.
·>Т.е. в конце месяца ты узнаешь, что у вас сломано создание statement? Это уже очень поздно. Ты получишь злобное письмо как минимум от каждого десятого юзера.
Вы снова занялись фантазированием. Вот проверили вы список проблем со значением в конфиге, условно, 5 минут.
А потом на проде вылезла новая проблема ровнёхонько через месяц
— например, задачи на создание стейтмента создаются, но висят ибо очередь забита чего у вас в тестах не было из за недостаточной загрузки
Все что вы можете
1. покрыть тестами всех уровней
2. проверять регулярно на проде, что бы обнаружить проблему до того, как напорются пользователи
P>>Мы уже выясняли — вы держите только ту часть acceptance, которую можно выполнить за полчаса. А другие на идут дальше этого 1%
·>Нет, мы дизайним так, чтобы любой acceptance можно было выполнить за пол часа, даже для сценариев которые требуют sleep(1 month). Время-то мочёное.
Значит это никакой не acceptance если вы мокаете время. Вероятно, это ваша местная специфика.
P>>Интеграционными — средний уровень в пирамиде. Я ж вам объяснял уже.
·>Какая часть приложения требуется для прогона такого теста?
Повторяюсь уже
new controller(параметры)
Отдельные части это технически вообще как юнит-тесты.
P>>Что вам непонятно было в прошлый раз? Вы продолжаете задавать один и тот же вопрос, получаете один и тот же ответ. Чего вы ждете?
·>Что вам непонято было в прошлый раз? Вы продолжаете гнать пургу про запуск тестов в проде случайным образом в случайные моменты времени.
Прогон тестов на проде это не моя придумка. Уже лет десять назад было довольно популярной практикой.
P>>Вы же сами сказали — у вас ажно 1% покрыт. Вот на остальные 99% и нужно придумать чтото получше чем есть у вас.
·>smoke-тестом — да, ~1%. А больше и не надо.
А acceptance сколько покрывает?
P>>Теорема Райса с вами не согласна. Нету у вас 100% надежного способа гарантировать даже true из boolean.
·>Верно, т.е. эти ваши тесты ничего нового не дадут.
мой подход сродни статической типизации — на него теорема Райса не действует
·>Я же объяснил, для управления этим используются другие средства вместо прогона тестов.
Вы эти другие пока не показали. Вам удобнее обсуждать тесты отдельно от дизайна.
P>>Вашу интеграцию тестируют acceptance и smoke. я вот не удивлюсь, если окажется что ваши acсeptance это ровно то же, что и e2e
·>Зависит от терминологии. Acceptance работают с моками внешних систем. Это считается как e2e?
Условно, да
P>>А также те, для которых тесты существуют, но причин более одной, разница прода и стейджа итд.
·>Разница в чём? У бинарников полное совпадение до бита. Отличаться могут только конфиги, и это контролируется diff-ом.
Нагрузка, данные, энвайрмент, время, сеть — отсюда и лезет недетерминизм.
·>Если только недетерминизм есть какой-то, из-за ошибок в многопоточке, например. Но такое тестами и не найти, тем более на проде. Если только случайно повезёт.
Именно для этого некоторые конторы в момент максимальной нагрузки запускают тесты прода. Это не шутка.
Таким образом тестируется система в нагрузке.
P>>А еще он поможет подсветиться лампочке в мониторинга до того, как юзер напорется на проблему, а не после
·>Это как? Вызвав нехватку ресурсов?
Например, потому что запускается в момент большой загрузки.
P>>Комбинаций у вас нет. Так?
·>Комбинации есть ровно те, что что и у вас.
Так и у меня их нет. И мой подход основан на пост-условиях. Это почти что статическая типизация, с некоторым упрощением.
P>>Мой подход того же поля что и статическая типизация — проверяет структуру, синтаксис.
·>Для проверки статической типизации изобрели компиляторы. Тесты статическую типизацию проверять не могут в принципе.
В том то и дело. И пост-условия тесты тоже заменить не могут.
1 типизация, пост-условия, инварианты, пред-условия, структурная эквивалентность используются, когда у нас есть только свойства результата
2 тесты — когда есть часть результата
Т.е. если у нас есть хитрый ORM, то мы можем добавить такой тип
Limited<Query, NoLongerThan<10>>
Поскольку такого ORM нет, то вместо статической типизации я подбираю инструмент c похожей механикой — пост-условия, структурная эквивалентность
А вот тесты здесь играют совсем другую роль — они фиксируют наличие пост-условия.
P>>Структурная эквивалентность, синтаксис теореме Райса не подчиняются.
·>Это и означает, что ваш тест проверяет, что works as coded. Абсолютно бесполезное занятие.
work as coded это если копировать sql из приложения в тесты.
А если в приложении билдер, а в тестах — его выхлоп на конкретных параметрах, то мы напрямую проверяем маппер — о большинстве проблем вы узнаете еще до запуска на реальной базе данных
P>>А вот ваши тесты это чистой воды семантические свойства которые полностью подчиняются теореме Райса
·>Так тесты и должны проверять семантику. Не гарантировать корректность семантики, а проверять для конкретных примеров. Тесты делают не с целью верификации свойств кода, а с целью упрощения написания кода, как исполнимая документация.
Ну так конкретных примеров то нет. А раз так — то используем "1 типизация, пост-условия, инварианты, пред-условия, структурная эквивалентность"
P>>Ваши тесты ничего не дают без знания конкретных комбинаций на которых можно отработать тест
·>Ваши тоже.
Вы пока не смогли пример адекватный привести, который сломает хотя бы примитивный limit 10.
P>>У Буравчика как раз тот случай, где нужны моки. Я же сразу это сказал, а вы третий месяц срываете покровы.
·>Мне ещё не довелось увидеть случая где не нужны моки. И ты правду скрыавешь.
Потому, что вы изначально думаете в единицах моков, и почти всё к ним и сводите.
P>>В том то и дело, что не даёт. У вас нет комбинаций, а потому проверяние количества записей смысла не имеет — в тестовой базе просто нет тех самых данных.
·>У меня ровно те же комбинации, что будут и в твоих тестах. Отличается только часть в ассертах. Вместо проверки синтаксиса — sql-код запускается и валидируется интересный с тз бизнеса результат.
Комбинации в бд не показывают проблему. Следовательно, вы вытащите её на прод.
Хотите устранить — нужно чтото большее, чем проверка комбинаций
P>>В прод коде только билдер. Откуда копипаста взялась?
·>В прод-коде у тебя будет реализация, "LIMIT 10", в тест-коде у тебя будет .eq("...LIMIT 10").
.
Не будет. Нигде в коде приложения нет явного LIMIT 10. Лимит вычисляется билдером. Будет ли это LIMIT или подзапрос с нужным выражением — дело десятое.
Важно, что лимит будет обязательно. И мне не надо перебирать всю таблицу истинности билдера на интеграционных тестах.
P>>Это всё из другого проекта, я им больше не занимаюсь
·>Ну сделай набросок, чтобы понятно было.
Все что мог, я вам показал. Что еще нужно? Запрос вы видите. Он собирается из разных частей. Каждая тестируется по отдельности.
Главное что бы структура была корректной.
P>>·>Нашел. Там нет ответа на мой вопрос.
P>>Попробуйте заново сформулировать вопрос. А на ваши огрызки цитат ответы ищите в синих буквах.
·>Используя какую бд проверяется паттерн запроса вручную, _до того_ как появится "тест против бд минимально заполненной под задачу"?
P>>А вот у пост-условия такого ограничения нет в принципе.
P>>Идея понятна?
·>Понятна конечно, я это тебе и говорил. Вот только постусловие ты проверить не сможешь тестом.
Тестом я не проверяю пост-условие. Тестом я проверяю, что оно на месте.
P>>·>Что за свойство длины?
P>>Известно какое — в память не влазит 
·>Что не влазит? Кому не влазит? Нихрена не понял.
Результат запроса не влазит в память.
