Имхо, дерьмово выглядит

друг от друга зависимые тесты тоже выглядят так себе

Почему?

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

Нет, значит

совсем нет

А с параллельностью это должно дружить?

В моем случае значит

авторизация тут как прекондишн идет

по сути

Должно. И тут зависимости тоже роялят. Либо вручную выстраивать, либо зависимости. Плюс, при добавлении нового метода, если указать зависимость, подтянутся остальные зависимости

Зачем? только ради того чтобы не выполонять тесты при падении?

На вопрос сколько тестов всего есть ответ?

Зачем? только ради того чтобы не выполонять тесты при падении?

Этого мало?

Сколько?

Достаточно много, если есть необходимость зависимостей.

Я закончил)

Я рад за вас. Обсудили всё, кроме моего вопроса

Одному человеку было полезно минимум(Дмитрию). А ты обращайся.

по-моему, Dorki Porki выразил свою мысль доступно. почему не организовать эти тесты в тест-сьют и не упорядочить их в нём?

Всем привет. Посоветуйте плз что можно почитать по тест дизайну.

К примеру, если я покрываю автотестами следующий функционал: * Произведение пополнения электронного кошелька. * Проверка в разделе операций, что транзакция пополнения отображается, и все поля верны. По сути, это 2 разные проверки, соответстевнно 2 разных теста, но они частично зависимы. Насколько я знаю, зависимость тестов не есть хорошо, т.к. если валится один, то и последующие валятся из-за него. Насколько правильно в таком случае пихать это в один тест? Сделал пополнение -> сразу же проверил, что в транзакции всё соответствует действиьльности (сумма, комиссия и т.д.). Или лучше разбить их на 2, и в случае с проверкой транзакции в операциях иметь как прекондишен юзера, с совершенной операцией и просто проверить поля на соответсвие?

Всем привет. Посоветуйте плз что можно почитать по тест дизайну.

не знаю, есть ли на русском, но когда-то читал "A Practitioner's Guide to Software Test Design" Ли Копленда

К примеру, если я покрываю автотестами следующий функционал: * Произведение пополнения электронного кошелька. * Проверка в разделе операций, что транзакция пополнения отображается, и все поля верны. По сути, это 2 разные проверки, соответстевнно 2 разных теста, но они частично зависимы. Насколько я знаю, зависимость тестов не есть хорошо, т.к. если валится один, то и последующие валятся из-за него. Насколько правильно в таком случае пихать это в один тест? Сделал пополнение -> сразу же проверил, что в транзакции всё соответствует действиьльности (сумма, комиссия и т.д.). Или лучше разбить их на 2, и в случае с проверкой транзакции в операциях иметь как прекондишен юзера, с совершенной операцией и просто проверить поля на соответсвие?

Это очень тонкий момент получается. И уже может зависеть от самой системы, от сложности "произведения" и "проверки" и от того как пишутся тесты впринципе. В идеале - разделять ) Иметь юзера может быть не достаточно(восстанавливать базу). Нужно делать нового юзера с выполненным флоу. Либо делать для существующего юзера.

не знаю, есть ли на русском, но когда-то читал "A Practitioner's Guide to Software Test Design" Ли Копленда

спасибо

Очень Грубо говоря ты точно определяешь что Выполняешь и что Проверяешь. Далее те Выполнения, что покрыты проверками можешь спокойно использовать в других тестах или для генерации данных для тестов.

Просто в данном случае, мне кажется эти 2 пункта имеют прямую зависимость между собой и может быть много подводных камней между фронтом и возвращения данных с бека ( та же комиссия может отображать одну сумму перед оплатой и после), поэтому разделять их не хотелось бы

Надо фукционал смотреть. Так для проверки комиссии отдельный тест получается уже) Я же говорю В Идеале, а так делают тесты, выполняющие несколько операций(которые можно проверить и отдельно) и смотрят результат.

Либо, прогонять какой-то стэк @smoke вначале к примеру (где просто проверяешь, что сами операции выполняются), и если ничего не фейлится, то дальше запускать уже полную регрессию

В общем вариантов уйма и не знаю на каком остановиться

Либо, прогонять какой-то стэк @smoke вначале к примеру (где просто проверяешь, что сами операции выполняются), и если ничего не фейлится, то дальше запускать уже полную регрессию

Да, это то, что я пытался донести человеку выше.

Ясно, спасибо. Буду думать.

Ясно, спасибо. Буду думать.

Смоук в любом случае стоит выделять, потому что он будет(должен) говорить о целых частях системы или ключевых функциях. Что определяет необходимость выполнять остальные проверки либо фиксить в скором порядке

по-моему, Dorki Porki выразил свою мысль доступно. почему не организовать эти тесты в тест-сьют и не упорядочить их в нём?

ну так потому что будет либо цепочка зависимостей от теста, либо цепочка зависимостей от тест сьютов.

Так какая разница, зависимость от тестов, или зависимость от сьюта?

куашник нашел ошибку, но как и при каких обстоятельствах чето не понятно. И разбираться с этим не очень хочется.

Ну и не обязательно разбираться, на что разработчики существуют.

Э, не понял.. Разработчики существуют на зарплату и левак-фриланс. Или это о чем было?

Ну и не обязательно разбираться, на что разработчики существуют.

разработчики существуют? О_о

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

А вот за это - надо просто мочить в сортирах. Это конкретный саботаж.

типа крэшится проложение, но шагов нет - знач фича

норм подход)

Если ты включаешь приложение и оно крешится => шаги воспроизведения есть.

А нет - это когда ты заводишь тикет, в нем пишешь "приложение крешится". Собирается комиссия, ты 5 раз включаешь приложение и ничего не крешится.

ну приложи логи после крэша

попробуй шаги найти

вспомни что ты делал до крэша

дай хоть какую-то инфу куда копать

у человека боковой амиотрофический склероз, он болен, но никто не умеет вопроизводить эту болезнь

значит это не болезнь!

это фича человека

причина возникновения - не ясна, болеют люди редко, но метко!

видимо))

значит это не болезнь!

Болезнь, но лечить ее не будут, т.к. непонятно чем.

Болезнь, но лечить ее не будут, т.к. непонятно чем.

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

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

да, считать

> у человека боковой амиотрофический склероз, Если так сформулировано, значит уже прочеканы все критерии и даже поставлен диагноз. Это сформулированный хороший баг.

воспроизводимости нет

Это вообще не относится к воспроизводимости

Воспроизводимость - это когда человек болен и дома и в поликлинике. А если по приезду в поликлинику он резко выздоравливает, то это - не воспроизводится.

И врачи такие тикеты закрывают со статусом "больше гуляйте, меньше нервинчайте, попейте витаминок"

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

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

Документировать. А вот считать багами или нет - это уже вопрос софистодемагогии +)

А вообще это сообщения я больше писал про конретно мой случай т.к. у нас довольно много граничных поведений, если на каждый чих создавать тикет то их штук 200 накопится. Лучше это время потратить как раз на фундаментальную переделку архитектуры и написание отладочных инструментов.

Звучит как "мне лень подчищать свои баги, хочу рефакторить".

+

хотя скорее не свои, но в целом да. оно и понятно - задокументировать 200 багов тож кусок работы.

я уже пробовал подчищать баги вместо того чтобы рефакторить и дела двигались в 5 раз медленнее. Хорошая попытка, "эффективные менеджеры", но нет.

Один день рефакторинга закрывает багу как класс, и не нужно подобные баги месяцами потом разгребать.

лол.

не считать багом баг это прям таки серьезное заявление я бы сказал..

Хе хе :)

А если кто-то влез ручками в базу стейджинга, там чето подредактировал, а потом система сломалась, то это баг или нет? =)

это человек-жук

Баг системы безопасности. Нечего давать в базу стейджинга кому попало доступ :) А влезшему откусить руки по самую шею

Ну у вас и методы, коллега!

Хорошие методы. правильные.

но более правильно было бы не допустить такого.

Что нас приводит к чему? Правильно, к фундаментальному рефакторингу инфраструктуры

А если кто-то влез ручками в базу стейджинга, там чето подредактировал, а потом система сломалась, то это баг или нет? =)

Конечно баг. Надо делать фоллбэки на случай некорректных данных, что бы, как минимум, ронять работу с конкретной entity, а не всю систему.

не доверять собственному коду и защищаться от себя самого? Шизофрения

Нет, это называется профессионализм. Тем более, что речь не о коде, а о данных.

Данные в базе считаются корректными

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

А если кто-то влез ручками в базу стейджинга, там чето подредактировал, а потом система сломалась, то это баг или нет? =)

а за такое по ручкам бить надо.

Данные в базе считаются корректными

С чего бы это?

Потому что если реально защищаться в каждой строчке от некорректных данных то это сразу комбинаторный взрыв.

Что нас приводит к чему? Правильно, к фундаментальному рефакторингу инфраструктуры

с таким успехом можно просто всегда рефакторить код, не заводя багов

С чего бы это?

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

Да и вообще вся индустрия ПО как бы строится на том что верхний слой доверяет нижнему. И если мы начнем еще сомневаться что в БД лежат правильные данные то сразу гроб гроб.

Вся индустрия ПО строится на том, что любое серьезное приложение - это комбинаторный взрыв состояний, и вы никак не можете контролировать данные и состояния ентитей. Поэтому фоллбэк на фоллбэке, обратная совместимость моделей данных и вот это всё.

"Да и вообще вся индустрия ПО как бы строится на том что верхний слой доверяет нижнему. " - вот с этим не могу согласиться. Все что встречал - работает условие "фронт никогда не доверяет бэкенду. И наоборот" Это кажется логичным и для других зависимостей

Но если вы можете внутри своего ПО гарантировать, что entity созданная N лет назад будет консистентной и полностью работоспособной относительно текущей системы - good for you.

"Да и вообще вся индустрия ПО как бы строится на том что верхний слой доверяет нижнему. " - вот с этим не могу согласиться. Все что встречал - работает условие "фронт никогда не доверяет бэкенду. И наоборот" Это кажется логичным и для других зависимостей

Бэкенд не доверяет фронту - это нормально. А вот фронт не доверяет бэкенду - это как?