Есть идеи как можно автоматизировать тесты без программирования и без Selenium , например возможно ли это делать в Jira Xray ? Или ещё какие либо идеи по автоматизации регрессионных тестов

как можно автоматизировать тесты без программирования и без Selenium

По принципу - делай "как я".

если есть что то ответить по делу, то можете сказать

ответ - именно так как спрашивали, или хотите пример?

https://www.tricentis.com/products/automate-continuous-tes...

только не спрашивайте про цену

хотелось бы что то в направлении Xray , т.к. внедрять хотя бы даже Selenium в проект, предприятие быстро не может

А с чего вы взяли что XRay это для "автоматизации тестов без программирования"? Так-то это просто продукт для менеджмента тестов. И интегрируется в тот же селениум. Насколько я помню,

Ну и автоматизация тестов без программирования... Многие такое обещают, ни разу не видел чтобы работало. Что Ranorex, что UiPath, везде приходится что-то кодировать.

хотелось бы что то в направлении Xray

для этого нужно хотя бы знать это направление

Вот еще попалось

https://www.testim.io/test-automation-tool/

предприятие быстро не может

А с какого бока тогда оно сможет быстро внедрить что то другое? И отчего быстро? Всё требует времени.

Поэтому я и спрашиваю про Xray потому как оно уже есть,и пока ничего другого нет хочу с этим поработать

Ответы уже нашла в интернете, так что тема закрыта

Ну так расскажите что нашли интересного?

Может еще кто то захочет попробовать

если вы такой умный, может поможете ещё ?

Я хочу сгенерировать ключ,и в последней команде не находит ничего

Какая то странная комбинация путей от винды и юникса. Вы под какой системой это делаете? Попробуйте точно такой путь как указано.

Под юниксами должно быть что то типа этого

в последней команде не находит ничего

-----

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

Какая то странная комбинация путей от винды и юникса. Вы под какой системой это делаете? Попробуйте точно такой путь как указано.

Это у него cygwin-овское окошко. Этакое "юниксовские утилиты под виндой". Ответ на его скриншоте, но товарисч не может две строчки прочитать. Зато выпендрону выше головы. Ему к алексу, пусть общаются :)

ещё одна просвещённая, не понимаю где ты увидела "выпендрон " с моей стороны. Я попросила нормального совета, т.к. я учусь этому только.

ещё одна просвещённая, не понимаю где ты увидела "выпендрон " с моей стороны. Я попросила нормального совета, т.к. я учусь этому только.

А, корнет, вы женщина? По стилю общения не понял. Ну и если в вашем селе это - нормальное общение, то лично для меня - нет. Семки сплюньте.

если есть что то ответить по делу, то можете сказать
Ответы уже нашла в интернете, так что тема закрыта
если вы такой умный, может поможете ещё ?

какой привет, такой ответ!

Ну вот шо вы такие злые? Это ж девушка из темы:

Хочу стать программистом - Программирование (germany.ru)

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

Мадам, вы все такие наполненные желчью, чем же вас так жизнь обидела... хотя меня это абсолютно не интересует.

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

обратитесь за помощью и консуацией в фирму Imbus AG

Я тут подумал - если юнит тесты не покрывают все возможные кейсы вашего кода, то они почти бесполезны. Особенно при подходе TDD - сначала тесты, которые покрывают все кейсы поведения и "описывают" его, а потом код. По-моему, это какая-то чушь. Под тесты, описывающие поведение, можно написать множество вариантов кода, которые все будут проходить тесты, но валиться на кейсах кода, которые не описаны тестами. А тесты и не должны описывать все кейсы кода - они первичны и описывают лишь все кейсы поведения. В TDD ничто не запрещает иметь коду дополнительное поведение, не покрываемое тестами. В противном случае, кто или что контролирует, что код не имеет других поведений, кроме описанных тестами?

Ну а если я много прототипирую и меняю код по 20 раз в месяц, даже если немного, то написание тестов к коду - просто бесполезная двойная работа, т.к. у меня и кейсы бизнес-логики, и кейсы кода постоянно меняются. Юнит тесты нормально писать к более-менее устоявшемуся коду, меняющемуся редко - т.к. когда код первичен. И то разумно требовать не 100% покрытия, а лишь основной части.

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

Каждый раз, когда сажусь писать тесты, в голове стойкое ощущение ненужной дурацкой работы. Особенно, если есть стремление к 100% покрытию.

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

А кто требует 100% покрытия?

Итого, TDD - надуманная хрень от извращенцев

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

Ну и тесты хотя бы раз написать, тоже полезно. Я даже когда для себя проекты делаю, часто пишу тесты. Очень удобно, во первых знаешь что данная часть работает как хочется, а во вторых видно когда накосячил.

и меняю код по 20 раз в месяц

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

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

в голове стойкое ощущение ненужной дурацкой работы

вариантов почему может быть много, неизменно одно - тесты полезная вещь

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

А кто требует 100% покрытия?

Вы прочитайте, что я написал. ТДД описывает тестами желаемое поведение программы, а не кода. Под такое поведение и прохождение всех тестов можно написать много вариантов кода. Но не все варианты выполнения кода будут покрыты такими тестами. Кроме случаев, конечно, когда абсолютно все ветки выполнения программы описаны тестами, учитывая любое поведение кода. Но это малореально.

Ну и тесты хотя бы раз написать, тоже полезно. Я даже когда для себя проекты делаю, часто пишу тесты. Очень удобно, во первых знаешь что данная часть работает как хочется, а во вторых видно когда накосячил.

А надо не часто, а постоянно. Слабо? ))

Я вот тоже щас у себя пишу, но т.к. код постоянно меняется, то смысла в этом особо нет. Пишу лишь там, где более-менее скоро менять не буду.

и меняю код по 20 раз в месяц

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

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

Вы не разу прототипы не делали, или то, что пока не знаете, как будет выглядеть окончательно? Всегда всё строго в соответствии с планом и по бумажке? А кто план составил и бумажку написал - старшОй? ))

ТДД описывает тестами желаемое поведение программы, а не кода. Под такое поведение и прохождение всех тестов можно написать много вариантов кода. Но не все варианты выполнения кода будут покрыты такими тестами. Кроме случаев, конечно, когда абсолютно все ветки выполнения программы описаны тестами, учитывая любое поведение кода. Но это малореально.

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

Например, тесты этой функции должны содержать:

- сложение должно выполняться правильно (кейсы на входные параметры и проверку результатов),

- функция не должна бросать исключения.

Как выполнить второй пункт? Если позволить бросать исключения, то надо перечислять какие и проверять, чтобы они бросались. Но все не перечислишь. Тогда нужно перечислить основные и остальные объединить под общим исключением (типа Exception). Так?

ТДД описывает тестами поведение программы, а не кода

Мне кажется, у вас не совсем верное понимания принципов ТДД.

что пока не знаете, как будет выглядеть окончательно?

на каждом этапе я знаю конечную цель, иначе как тогда вообще что-то писать?

Некоторые части, да могут меняться, но не каждый день. Похоже всё таки дело в коде.

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

Но они оба покрываются одинаковыми тестами.

Я тут подумал - если юнит тесты не покрывают все возможные кейсы вашего кода, то они почти бесполезны.

Тесты и не должны покрывать все кейсы кода :) Тесты должны описывать требования к коду.

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

Значть нужно будет проанализировать проблему --> сформулировать новой требование --> написать новые тесты.

В TDD ничто не запрещает иметь коду дополнительное поведение, не покрываемое тестами.

Не запрещает. Так что как ничто не запрещается тебе писать код не обращая внимание на требования :)

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

Это значит, что у тебя проблемы с проектированием софта. Тест тут не виноваты.

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

Никто и не говорит, что тесты - это панацея от чего-либо.

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

А не нужно все. Достаточно 1-2 регурярных тест-кейса и (если нужно) пара пограничных. Если в процессе жизни окажется, что чего-то не хватает, то всегда можно добавить необходимые тесты.

PS: юнит-тесты - это регриссионное тестирование, т.е. задача юнит-тестов состоит в том, чттобы заявить, что наложенные на компоненту требования исполняются. Ошибки в коде не ищутся юнит-тестами.

А не нужно все. Достаточно 1-2 регурярных тест-кейса и (если нужно) пара пограничных. Если в процессе жизни окажется, что чего-то не хватает, то всегда можно добавить необходимые тесты.

PS: юнит-тесты - это регриссионное тестирование, т.е. задача юнит-тестов состоит в том, чттобы заявить, что наложенные на компоненту требования исполняются. Ошибки в коде не ищутся юнит-тестами.

Ну вот оно так и получается. А как сделать, чтобы все кейсы кода покрыть? Чтобы не было неожиданных выбросов и поведений?

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

Это значит, что у тебя проблемы с проектированием софта. Тест тут не виноваты.

Конечно проблемы. Если я первый раз в теме, и ещё не знаю, как всё работает, а моя идея ещё до конца не оформилась, и я меняю поведение в зависимости от пришедших новых идей, то будет по 20 изменений в месяц.

А как сделать, чтобы все кейсы кода покрыть?

Зачем? Вот добавил тест если значение между 1 и 3, то выбрасывается исключение. Ок 100% покрытие теперь.

Только вот сколько еще искать, а какого фига раз в день, а то и реже выбрасывается это исключение в проге?

и ещё не знаю, как всё работает, а моя идея ещё до конца не оформилась

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

При правильном выборе новые расширения, просто добавляются в существующий код.

Я вижу проблему в том, что вы категорически отказываетесь чему то учится. Мол всё это чушь собачья. Какая нафиг vertical slice архитектура, когда нас и тут неплохо кормят и никакой Гаити нам не нужен

и ещё не знаю, как всё работает, а моя идея ещё до конца не оформилась

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

Есть ситуации, когда решение может прийти лишь в процессе, итерационно.

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

При правильном выборе новые расширения, просто добавляются в существующий код.

Какие расширения? Куда? Нет ничего, кода нет, тестов нет. Нечего расширять.

Мне кажется, у вас не совсем верное понимания принципов ТДД.

Сеньёр-разработчик объясняет правильный подход к ТДД

Есть ситуации, когда решение может прийти лишь в процессе

Что то мы опять о разном говорим похоже.

Ну вот простой пример, мне нужна логин форма для приложения, как это будет в итоге делаться не имею никакого понятия.

Решаем, что будем вызывать какое то апи. На входе мейл и пароль, на выходе токен.

Для начала, делаем сервис который просто возвращает токен.

После добавляем в сервис регистрацию в памяти. Затем добавляем вызов стороннего АПИ.

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

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

какие то искаженные представления

ну хотя бы так

https://habr.com/en/companies/ruvds/articles/450316/

Есть ситуации, когда решение может прийти лишь в процессе

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

Не надо простых примеров. С логин-формой всё как раз понятно - логин и пароль.

А вот если вы налепите все свои заготовки, а потом придут и скажут, что теперь тут будет не логин и пароль, а 5 разных других параметров. А через неделю - 3 других. А потом опять к логину и паролю вернёмся. Или не вам придут и скажут, а вы сами решите.

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

какие то искаженные представления
ну хотя бы так
https://habr.com/en/companies/ruvds/articles/450316/

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

А уж как подтираются всеми этими пафосными декларациями, когда дедлайн клюёт жареным петухом в задницу... Тут и маститые сеньёры ходят, красные до ушей. А потом и времени нет привести всё в порядок. А потом: - можете показать ваш код? - не могу! )))

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

Для регрессионного тестирования не нужно ТДД. Вы сначала можете писать код, а потом тестировать его. А уже потом следить, чтобы он не регрессировал с помощью тестов. А когда делаете прототип, то код идёт вперёд тем более.

Когда в голове возникает мысль, вы её проверяете кодом, а не написанием кучи тестов. Тот, кто не приступает к программированию без тестов, должен быть последовательным, и требовать также полной спецификации, всех юзер сторис, и обязательно широкого ассортимента свежих смузи каждый день. Без этого же нельзя нормально писать код!

А теперь новая область

Не играет особой роли. Всегда есть эксперт(ы) предметной области, вот их и нужно трясти штормом.

Тем более, когда результат охота увидеть прям щас

именно так и делается. И вместо текста - Lorem Impsum

что теперь тут будет не логин и пароль, а 5 разных других параметров. А через неделю - 3 других

ну это уже неправильный подход к разработке.

Хотя тоже бывает, было помню согласованное ТЗ с заказчиком, но заказчиком был шеф, а когда привезли все в цех, работник говорит - а нам так не нужно, нужно по другому. И что всё с нуля переписывать, нет конечно. На месте просто модули соединили по другому.

Но даже если идти как написано, меняется то всего одна страница, все остальное остается как есть.

Да читал я все эти слащавые статейки чуваков

Есть большое сомнение, что при этом был понят и смысл

Вот еще один чувак, который нифига не понимает в программировании, но лезет на сцену

Ок, удаляем всё что было и делаем по новому.

-----

Нефига не удаляем! Вообще не удаляем если получен работающий код.

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

заставляем порождать вторую версию логина

А кто сказал, что это вторая версия логина?

Вместо логина, хотят номер телефона, адрес и номер счета в банке.

Так вот откуда появляются уроборосы фабрик и лабиринты декораторов, порождающих друг друга в бесконечном цикле, после 10-15 лет поддержки старого кода! Просто каждый следующий не хочет разбираться, а оборачивает всё в очередную свою обёртку.

А Фабрике - пофиг какая - хоть 25, хоть 2005...

заставляем порождать вторую версию логина

А кто сказал, что это вторая версия логина?

Вместо логина, хотят номер телефона, адрес и номер счета в банке.

Нужна адаптирующаяся фабрика стратегий по построению разномастных логин-форм.

Есть большое сомнение, что при этом был понят и смысл

Вот еще один чувак, который нифига не понимает в программировании, но лезет на сцену

Он уже оскомину набил. У него последние 20 лет работа - консалтинг и коучинг. Вот он себя и продаёт со сцены.

какие то искаженные представления

ну хотя бы так

https://habr.com/en/companies/ruvds/articles/450316/

Дочитал до того места, где он сделал ошибку в операторе IF. Ну штош.

Зачем мне нужен мертвый код?

Ладно, оставим персону автора в покое. Сосредоточимся на содержании. Что можете сказать по этому поводу?

Дочитал до того места, где он сделал ошибку в операторе

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

И код в подобной статье всего лишь некая иллюстрация сказанного, в который я лично даже и не всматривался /там не C#/, а если бы и разбирался, то какие либо проблемы с кодом были бы совершенно не важны.

PS: юнит-тесты - это регриссионное тестирование, т.е. задача юнит-тестов состоит в том, чттобы заявить, что наложенные на компоненту требования исполняются. Ошибки в коде не ищутся юнит-тестами.

Слегка сумбурно. Юнит-тесты это не обязательно регрессионные тесты. Ими ещё и интерфейс тестировать удобно. Как раз поиск ошибок в имплементации. По требованиям если у меня второй параметр пустая строка мне должен код вернуть NOK а он бросил исключение.

Потому как завтра тебе скажут все вернуть обратно, а послезавтра - все снова перевернут...

Потому как завтра тебе скажут все вернуть обратно, а послезавтра - все снова перевернут..

нут так для этого есть гит.

Нее, для этого есть конфиг...

Ладно, оставим персону автора в покое. Сосредоточимся на содержании. Что можете сказать по этому поводу?

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

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

Ладно, оставим персону автора в покое. Сосредоточимся на содержании. Что можете сказать по этому поводу?

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

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

А баг, длящийся почти 3 года (это лишь с момента публикации того сообщения), и помеченный как "решённый"? На любой логин с любого устройства, с любой локали их сайта (а ведь у них на каждую локаль свой залогин), даже с того же самого, ты получаешь "тревожное письмо", что кто-то пытался зайти на твой аккаунт с "нового" устройства - это точно был ты? И "изящное решение" - да просто игнорь и удаляй этот "спам". И отказаться от получения таких писем нельзя. Какие, мать вашу, юнит тесты, Дяди Бобы и прочие шняги могут помочь извести всех этих ублюдков, получающих бешеные зарплаты и делающих нихрена для решения реальных проблем? Они пишут тесты? Наверняка. Исследуют фокус группы? А как же! Так какого хрена всё работает через жопу?! - Пошёл на..., у нас всё хорошо, дайвёрсити, инклюзивность, всегда на позитиве...

Ска, зла не хватает... И потом мне приходят такие и ездиют по ушам - а вот ты тестик не написал, а вот дядя Боб сказал..., а вот в ФААНГах-то... - это всё очень плохо и не бест практисес. Этот Дядя Боб и ему подобные эти ФААНГи и консультируют, а кули толку?

Сёдня полдня провёл с траханьем с багами этих мать их ФААНГов. Ну как баги - они на них давно забили и это уже давно фичи. У одних весь системник говном от инсталлятора забивается, у других сайт сделан через жопу и они гордятся этим и отфутболивают всех недовольных, и так далее. Зато у всех них зарплаты месячные как у меня годовая.

Этот видос не смотрел

Сложно с кем то разговаривать, если не "читал, но осуждаю." Давайте тогда своего любимого автора...

А мировые многомиллиардные корпорации делают проще

У меня за углом в садике, народ тоже попроще всё курит и бухает. Не обязательно равняться на них.

Можно ведь равнятся на что то более правильное

Судя по всему, правильное - это плевать на всех и зарабатывать миллиарды. Точнее, сначала зарабатывать миллиарды, а потом плевать на всех. Даже не тех, на ком их заработал. Задрачивать "чистый код", тестирование и прочую муру - явно не путь к успеху. Быстро на коленке слабать прототипчик, занять у лохов инвестиций, напихать доната, сорвать куш, кинуть лохов с долгами, отчалить в тёплые страны к домику у моря, на вырученные деньги нанять кодеров, которые переделают всё по уму, всем рассказывать, что всего добился сам, заняться коучингом со сцены в перерывах между мулатками и сёрфингом - звучит куда сексуальнее. ))

Давайте тогда своего любимого автора...

У меня нет любимого автора. ))

ну хоть кого то кто описал ТДД так вы считаете правильным, у кого-то учились или как?

Само ТДД неправильное. Особенно, когда на него молятся и пихают везде.

Само ТДД неправильное.

А что есть правильное?

Или только я делаю всё правильно, а все остальные только мешают?

только я делаю всё правильно, а все остальные только мешают?

Теплее.

Папка \Users\[userName]\AppData\Local\Temp полная?

PS: юнит-тесты - это регриссионное тестирование, т.е. задача юнит-тестов состоит в том, чттобы заявить, что наложенные на компоненту требования исполняются. Ошибки в коде не ищутся юнит-тестами.

Вы бредите белой горячкой.

Регрессионное тестирование это совершенно другой уровень тестирования и его сложности.

Это вообще святая святах всего QA: именно под регрессионное тестирование разрабатывается куча продуктов, которое стоит миллионы евро.

Оно выполняется на GUI уровне.

Каким боком вы сюда записали юнит тесты?

Зы. Вы только что не сдали ISTQB Foundation Level.

тут подумал - если юнит тесты не покрывают все возможные кейсы вашего кода, то они почти бесполезны.

Вы очень мало думали. Юнит тесты должны покрывать Main Paths SUTа.

Да, и в таких вещах нельзя думать. Это все есть в книгах, которые вы не читали.

мировые многомиллиардные корпорации делают проще - либо через жопу, как нам удобнее, либо пошёл на...

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

вроде ж можно было на eBay.con зайти под своим аккаунтом и будет тебе все на английском?

В TDD ничто не запрещает иметь коду дополнительное поведение, не покрываемое тестами

Покрывемое и не покрывемое тестами поведение обычно разделяют на уровне хотя бы методов.

Да ладно с тестами. Тут при переходе с плюсов на шарп завлекали, что теперь не надо памятью управлять - всё само делается. Правда, есть такая штучка, как Dispose, и правильное её написание в разы сложнее плюсового деструктора. И здесь нае...!!

вроде ж можно было на eBay.con зайти под своим аккаунтом и будет тебе все на английском?

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

Правда, есть такая штучка, как Dispose, и правильное её написание в разы сложнее плюсового деструктора

Ладно, я еще могу понять когда маленькие буквы не читают но большие то можно

https://learn.microsoft.com/en-us/dotnet/standard/garbage-...

The Dispose method is primarily implemented to release unmanaged resources.

Где обман то?

Делегаты и события в неоконных приложениях. Это как пример.

Например, не забыть такие мелкие детали, как заналлить ссылку на сервис. Зачем? И вот таких мелочей с dispose куча, и все необходимо помнить. Даже если работал с этой фигнёй год назад.

А деструктор прост как две копейки. Его может быть монотонно писать (но не сложнее конструктора, который деструктор наоборот), но соглашения об использовании просты - вызывай в своём деструкторе деструкторы других объектов, что используешь в своём классе. Кучу мелочей, типа финализаторов, SuppressFinilize и прочей мути, помнить не надо.

Делегаты и события в неоконных приложениях. Это как пример.

Пример чего?

Например, не забыть такие мелкие детали, как заналлить ссылку на сервис.

А причем здесь Dispose и обман? Это просто вариант решения конкретной проблемы.

Что-то у вас пафос брыжжет. Кому-то пора перепройти ISTQB-F.

Регрессионное тестирование это совершенно другой уровень тестирования и его сложности. ... Оно выполняется на GUI уровне.

Ну я даже и не знаю что сказать... Отправить почитать хоть что-то от ISTQB? Хотя бы определение регрессионного теста? Где там что-то про гуя, непонятно...

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

Регрессионное тестирование наиболее денежно именно для GUI.

С точки зрения продавцов инструментария.

И, так как автотесты для GUI по сути очень дорогие, то нужно выполнять регрессионные.

Регрессионные тесты SOAP и REST намного дешевле

И, так как автотесты для GUI по сути очень дорогие, то нужно выполнять регрессионные.

Т.е. получается что автоматизированные GUI (end-2-end) тесты не могут быть регрессионными? Или вы что-то другое имели в виду?

автоматизированные GUI (end-2-end) тесты всегда очень дорогие, поэтому их не нужно все специфицировать, автоматизировать и выполнять.

Они ничего не найдут. Нужно выполнять только их подмножество — автоматизированные регрессионные GUI тесты.

Именно они важны.

Зы. А когда-то давно в Германии был айти форум

Я бы посоветовал вам подучить русский язык. А то вас понимать очень сложно.

И вы по-моему не понимаете что такое регрессионный тест. Ну или давайте так. Попробуем ещё раз.

Они ничего не найдут. Нужно выполнять только их подмножество — автоматизированные регрессионные GUI тесты.

Чем отличается "автоматизированный GUI тест" от "автоматизированного регрессионного GUI теста"?

P.S. И если "они ничего не найдут", то зачем "они" вообще нужны? "Они" в ващем высказывании это автоматизированные GUI тесты, которые не являются регрессионными, верно?

Регрессионный GUI тест и обычный GUI тест представляют собой два разных подхода к тестированию графического интерфейса (GUI) программного приложения. Вот их основные различия:

1. Цель тестирования:

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

- Регрессионный GUI тест используется для проверки, не повредились ли существующие функциональности приложения после внесения новых изменений или исправлений. Он выполняется после каждого обновления или изменения в коде приложения.

2. Частота выполнения:

- GUI тест выполняется относительно редко, обычно на этапах разработки и тестирования новых версий приложения.

- Регрессионный GUI тест выполняется чаще, даже ежедневно, чтобы быстро выявлять проблемы, которые могут возникнуть после изменений в приложении.

3. Объем тестов:

- GUI тест может включать в себя широкий спектр тестов, которые проверяют различные аспекты интерфейса, такие как внешний вид, взаимодействие с элементами и т.д.

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

4. Автоматизация:

- Оба типа тестов могут быть выполнены как вручную, так и с использованием автоматизации. Однако регрессионные GUI тесты чаще автоматизируются, чтобы обеспечить более быструю и надежную проверку после изменений.

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

Регрессионный GUI тест и обычный GUI тест представляют собой два разных подхода к тестированию графического интерфейса (GUI) программного приложения. Вот их основные различия:
1. Цель тестирования:
- GUI тест проверяет, работает ли интерфейс приложения правильно и соответствует ли он спецификациям дизайна. Он обычно выполняется в начале разработки или после значительных изменений в интерфейсе.
- Регрессионный GUI тест используется для проверки, не повредились ли существующие функциональности приложения после внесения новых изменений или исправлений. Он выполняется после каждого обновления или изменения в коде приложения.
2. Частота выполнения:
- GUI тест выполняется относительно редко, обычно на этапах разработки и тестирования новых версий приложения.
- Регрессионный GUI тест выполняется чаще, даже ежедневно, чтобы быстро выявлять проблемы, которые могут возникнуть после изменений в приложении.
3. Объем тестов:
- GUI тест может включать в себя широкий спектр тестов, которые проверяют различные аспекты интерфейса, такие как внешний вид, взаимодействие с элементами и т.д.
- Регрессионный GUI тест обычно фокусируется на тестировании конкретных функциональностей или элементов, которые могли быть затронуты изменениями в коде.
4. Автоматизация:
- Оба типа тестов могут быть выполнены как вручную, так и с использованием автоматизации. Однако регрессионные GUI тесты чаще автоматизируются, чтобы обеспечить более быструю и надежную проверку после изменений.
Важно понимать, что регрессионные GUI тесты часто включают элементы обычных GUI тестов, но их основной упор делается на обеспечение стабильной работы приложения после изменений.

А когда большие компании, в которых сотрудники зарабатывают много шести- и семизнаков в год, выкатывают в релиз лагающее, неработающее и подвисающее овно, это у них обычный GUI не прошёл, или регрессионный GUI? Как вы думаете, обсуждают ли они в перерывах между выкатыванием дерьма в продакшен, что чьим подмножеством является, или смузи хлебаются и так, без обсуждений? Какой ISTQB whatever-fucking-Level завалили сотрудники Ебея, когда проектировали и релизили свой интерфейс с жёсткой привязкой локали к региону и валюте оплаты? А может, с размером их конторы и их зарплат, им просто плевать на эти чьи-то факинговые квалификации, и они сами кого хошь заквалифицируют? Вот прийдёте вы к ним со своими сертификатами, чтобы тоже вкусить от многошестизначных зарплат, а они вас прокатят и поржут над вами, когда вы будете им заяснять, как надо локализации на сайтах делать, и скажут, что у вас недостаточно знаний, чтобы работать в их дружной команде мировых специалистов. А вы их даже не успеете спросить, уважают ли они "дядю Боба" и смотрели ли его лекции. Что-то мне подсказывает, что при его упоминании в ответ можно услышать, что никаких факинговых дядь Бобов они не знают, а если таковой к ним придёт и осмелится читать лекции, то охрана быстро покажет ему, где выходная дверь.

))

когда проектировали и релизили свой интерфейс с жёсткой привязкой локали к региону и валюте оплаты?

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

Думаю, что в головы тамошних менеджеров залезть сложно.

А вот часто ли ебай вылетает при заказе или есть постоянные сбои в работе?

нп

Ищу для автоматического GUI-тестирования инструмент, где я мог бы записывать последовательность действий(мышь+клавиатура) примерно как в мс офис запись макросов.

Есть что-то такое на рынке?

Давайте лучше о том, что интерфейсе Ебея - лютое овнище, представляющее собой мешанину текста и картинок, непонятно как связанных. Структурирования, такое ощущение, нет никакого. Где один блок, где другой, и что за что отвечает. Чтобы понять описание товара, нужно прорыскать всю страницу. Плюс личные настройки находятся в двух менюшках, разнесённых по разным углам - верхняя правая и верхняя левая. Почему не поместить всё в одном месте? Думаю, такой антипаттерн дизайна сделан, чтобы пользователь постоянно шарился по всей странице, силясь найти нужные кнопки, описания и ссылки. Так он точно прошерстит всю рекламу, которой любая страница Ебея просто завалена.

Точно не знаю, вот хотел енто попробовать

https://github.com/testsigmahq/testsigma

Есть вроде и довольно дорогая версия.

...

Вот еще нашел

https://www.perfecto.io/products/scriptless#tab-panel-4536...

что интерфейсе Ебея

Уж и не помню когда в последний раз пользовал, сейчас открыл, ничего страшного не заметил.

Предлагаю написать им письмо с описанием нового интерфейса, может возьмут на дизайнера

хз что у тебя за проблемы с ибеем.

На телефоне не очень реализовано - нужно промотать до Artikelbeschreibung des Verkäufers - там все подробно описано.

В десктопной версии оно сразу на виду.

с такими вопросами позвоните в imbus ag

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

Квалификации и сертификаты, такие как ISTQB, могут быть полезными, но не всегда гарантируют качество разработки или управления проектами. Важно учитывать, что решения, принимаемые в компаниях, могут быть сложными и зависеть от множества факторов, включая бизнес-цели, ресурсы и сроки.

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

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

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

Как пользователь, вы можете выражать свои предпочтения и обратную связь на сайтах, таких как eBay, чтобы помочь им улучшить пользовательский интерфейс. Ваши комментарии и предложения могут внести позитивный вклад в развитие интерфейса и улучшение опыта пользователей.

Точно не знаю, вот хотел енто попробовать
https://github.com/testsigmahq/testsigma

Есть вроде и довольно дорогая версия.
...
Вот еще нашел
https://www.perfecto.io/products/scriptless#tab-panel-4536...

Непонятно, как эти штуки работают, если для GUI тестирования нужно не только на контролы понажимать и повводить что-то, но и визуально понаблюдать, что происходит. Вот это последнее эти системы как контролируют? Поэтому и нанимали раньше людей (пока в ФААНГах не стало модным на этом экономить), которые все кнопочки руками протыкивали и смотрели результат глазами. Ну максимум можно протыкивание автоматизировать, а наблюдать результат-то всё равно самому надо.

инструмент, где я мог бы записывать последовательность действий(мышь+клавиатура) примерно как в мс офис запись макросов.

https://www.ranorex.com/

У него была для нас одна проблема - работал исключительно под виндой. Поэтому сложно было его использовать в CI/CD.

Чисто из энтомологического интереса, а где вы эту псевдоразумную чушь нашли? Из статейки на хабре? "Дождь отличается от жидких осадков, потому что дождь идёт, а осадки выпадают". :)

1. Цель тестирования:
- GUI тест проверяет, работает ли интерфейс приложения правильно и соответствует ли он спецификациям дизайна.
- Регрессионный GUI тест используется для проверки, не повредились ли существующие функциональности приложения

Ога. "Работает правильно" и "не повредились ли". Прям огромная разница, понимаю.

Или вы хотите сказать что "гуи тест" тестирует интерфейс (ну, допустим, хотя в 99% случаев это просто синоним е2е), а вот РЕГРЕССИОННЫЙ гуи тест тот ого-го! он функциональность приложения тестирует! Ауф! :) Ну, т.е. является е2е тестом.

2. Частота выполнения:

Тут прям совсем ой. Выполняем два раза в день - регрессионный. Выполняем раз в неделю - не, не регрессионный.

3. Объем тестов:

Сдаюсь. Нет слов. Так-то все автоматизированные тесты стараются делать чем меньше, тем лучше. Про FIRST слышали? Но бывают и для регресса забабаханные монстры, работающие по 2-3 часа. Только не надо сейчас в дебри нагрузочных тестов / тестов производительности лезть.

4. Автоматизация:

Ну и очередная благоглупость. Чаще, реже...

Давайте я открою вам глаза. Любой тест, который мы повторяем (не важно после каждого или после каждого 10 изменения, каждый час или каждую неделю, за одну секунду или за 5 часов, юнит, интеграционный, компонентный, системный, е2е) можно назвать регрессионным. Главное чтобы тест не менялся между запусками и мы сохраняли предыдущие результаты тестирования. Всё. Никакого колдунства. Поэтому не надо этим термином размахивать. Он для автоматизированных тестов как напоминание про то, что дождь мокрый. ISTQB оно просто не про автоматизированные тесты. А про тестирование вообще. Ручками.

В случае автоматизированных тестов тоже можно использовать термин "регрессионный тест". Чтобы подчеркнуть одно - цель тестирования. Если мы пишем автоматизированный тест, которые не проверяет контракт, не интеграционный, не функциональный, то мы что? Мы называем его регрессионным. Мы хотим "зафиксировать" текущее состояние. Хотя оно нигде не предписано. Зачем это обычно надо? Защита от "побочных эффектов". Частый пример - использование конвенций наименований. Легко сломать код, по незнанию обозвав что-то так, что этот код на это имя среагирует. Тест, написанный как регрессионный это всегда white-box, всегда от деталей имплементации зависит. (ну, тут просто, да? black-box тест всегда можно обозвать контрактным тестом)

Да и ещё. Никогда, нигде и никто до вас не говорил такую чушь что "регрессионные тесты это гуи тесты". Вы - первый. :)

очно не знаю, вот хотел енто попробоватьhttps://github.com/testsigmahq/testsigma
Есть вроде и довольно дорогая версия....Вот еще нашелhttps://www.perfecto.io/products/scriptless#tab-panel-4536...

спасибо

помочь им улучшить пользовательский интерфейс

------

Бесполезно.

В большинстве случаев - отвечающий на описание проблемы не в состоянии понять суть проблемы.

Вот пример:

Тот же ЕБай... выбираешь место доставки - Ирландия, выбираешь валюту - евро... Все - Ок.

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

Проблема - элементарная, решение делается минут за 20-ть - описана детально и давно... но вопрос не решается уже более 3-х лет...

Чтобы у местных продавцов заказывать, там надо менять язык на язык вашего региона. Что там в Ирландии - не знаю. Ирландский английский? Вобщем, тогда поиск будет по местным продавцам, соответственно и доставка от местных, которая зачастую бесплатна, а не международная за десятки баксов. Может, они решили, что раз всё равно международную доставку никто не заказывает (невыгодно), то и привяжем жёстко локаль к локации? Но как быть иностранцам зарубежом, которые тоже хотят Ебеем воспользоваться? Как англоговорящему работать с Ебеем в арабских или азиастких странах с их иерогливами? Переводить страницу сервисами перевода?

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

-----

Зачем?

Мне нужны цены в той валюте в которой Я буду платить, в той, в которой счет, со всеми накрутками по обмену валют.

Мне абсолютно пофиг каков региональный язык места проживания/доставки - это нужно только для указания адреса - мне нужна информация на том языке который мне понятен.

Как англоговорящему работать с Ебеем в арабских или азиастких странах

Ему нужно только попросить всех продавцов писать описание на английском

Нефиг туристам покупать, что то на ебее...

у меня такое ощущение, что вы не айти специалист. И в своей жизни ничего тяжелее мышки не поднимали.

И с логикой в голове у вас огромные проблемы. Вч путаете посылку и заключение.

Ога. "Работает правильно" и "не повредились ли". Прям огромная разница, понимаю.

Разница огромная. И вы вырвали фразу из контекста

GUI тест проверяет, соответствует ли ПО спецификациям дизайна.

Которые обычно на полтора километра и выполняются месяцами или даже годами. А может быть даже и не выполнится

а вот РЕГРЕССИОННЫЙ гуи тест тот ого-го!

Вы русский язык сначала выучите. Что вы понимаете под ого-го ?

он функциональность приложения тестирует!

Хорошая попытка, но нет. Пытайтесь троллить где-нибудь в другом месте.

Регрессионный GUI тест используется для проверки, не повредились ли существующие функциональности приложени

Вы

Тут прям совсем ой. Выполняем два раза в день - регрессионный. Выполняем раз в неделю - не, не регрессионный.

Вы считаете, что если поменяли посылку с заключением, то стали самым крутым троллем на германке?

Регрессионные GUI тесты можно выполнять часто, так как они быстрые. Так как тестируют не по всей спецификации, а только по той, что может сломаться.

Конкретный пример:

О баге было сообщено производителю. Был написан автотест, который воспроизводит баг. Это будущий регрессионный тест. Производитель исправил его. Прогнали тест — он стал зеленым.

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

Поэтому не надо этим термином размахивать

Этим термином размахиваю не я, а очень много серьезных фирм. Но пришел вася с германки и начал ставить все под сомнение.

Так что становитесь в очередь за работой по разгрузке шин. Это для вас вполне посильная работа..

у меня такое ощущение, что вы не айти специалист. И в своей жизни ничего тяжелее мышки не поднимали.

Пф, тяжелее мышки не поднимал, но почему-то не IT специалист, а наоборот - должен шины разгружать... И этот человек рассказывает что я "посылку от заключения не отличаю" :)

Чего ж их не отличить. Посылки почта возит, а в заключении преступников содержат. Правильно?
троллить... Я ещё и не начинал. :)

Давайте, чтобы не растекаться мыслью... Всё что вы пока что писали - ерунда. Живите с этим :)

И вернёмся к истокам. Попробуйте всё же пояснить, какое отношение регрессионные тесты имеют к "GUI уровню" (и что вы вообще под этим понимаете).

Это вообще святая святах всего QA: именно под регрессионное тестирование разрабатывается куча продуктов, которое стоит миллионы евро.

Оно выполняется на GUI уровне.

Слив засчитан. Идите работать наклейщиком почтовых марок и разносчиком писем и пакетов, раз у вас такие ассоциации.

Вы к тому же понятия не имеете, чем отличается работа программиста при написании юнит тестов от работы инженера автоматизации в отделе QA при написании регрессионных GUI тестов.

Это разные должности, разные отделы, разные начальники, разные зарплаты, разные требования,.

Вам нужно пройти друг у друга собеседование. В закрытом помещении с подпёртой снаружи дверью и маленьким окошком для наблюдения. ))

А как сделать, чтобы все кейсы кода покрыть? Чтобы не было неожиданных выбросов и поведений?

Никак.

Однако надо сказать, что есть системы в которых требования к софту черезвычайно высоки (например авионика) в таких случаях покрытие юнит-тестами необходимое и очень дорогое удовольствие. Вообще говоря, стоимость покрытия кода юнит-тестами растет по экспоненте. Именно поэтому покрытие в 70-80% - это очень хороший результат.

Если я первый раз в теме, и ещё не знаю, как всё работает, а моя идея ещё до конца не оформилась, и я меняю поведение в зависимости от пришедших новых идей, то будет по 20 изменений в месяц.

В нормальных процессах все работает не так. Разработка сначала делается на бумаге, и только потом пишется код. При этом есть архитертор, который в теме. Так что 20 изменений делаются на бумаге и даже не в MVP.

Это вообще святая святах всего QA: именно под регрессионное тестирование разрабатывается куча продуктов, которое стоит миллионы евро.
Оно выполняется на GUI уровне

.Боюсь, что это вы бредите гелой горячкой:

Регрессионное тестирование — это проверка ранее протестированной программы, позволяющая убедиться, что внесенные изменения не повлекли за собой появления дефектов в той части программы, которая не менялась.

Регрессионное тестирование - это методика. Никакого отношения к GUI не имеет. Совсем.

Каким боком вы сюда записали юнит тесты?

Очень просто - есть тест и он зелененький. Ты делаешь изменение в коде и какой-то из уже существующих тестов становится красненьким -> внесенные изменения повлекли за собой появление дефектов в той части программы, которая не менялась.

Зы. Вы только что не сдали ISTQB Foundation Level.

Мне наплевать на ISTQB Foundation Level. Особенно, если на этом уровне надо непонимать базовые вещи.

Matthias Hamburg и Tilo Linz в роли смотрящих

Мне наплевать на ISTQB Foundation Level. Особенно, если на этом уровне надо непонимать базовые вещи.

Не-не, ISTQB-F штука полезная. Особенно для тестеров. Это товарища заклинило на гуях почему-то.

Вы к тому же понятия не имеете, чем отличается работа программиста при написании юнит тестов от работы инженера автоматизации в отделе QA при написании регрессионных GUI тестов.

Исчо б. А если программист сделает ну, например, селениум тест и он будет быстрый, проверять "функционал" и после каждого деплоймента выполнятся, т.е. получится (в вашей терминологии) регрессионный гуи тест, его расстреляют?

Да, так какое отношение "регрессионный тест" имеет к "гуи тестам"? Я-то необразованное быдло, понятно, но другим же тоже интересно. Может снизойдёте, на вопрос ответите?

Слив засчитан. Идите работать наклейщиком почтовых марок и разносчиком писем и пакетов, раз у вас такие ассоциации.

Не могу. Пакеты тяжелее мышки...

Это фирму Imbus AG заклинило

Не надо своих крокодильчиков на имбус перекидывать. У них всё в порядке. Я же вам даже ссылочку на определение присылал. Или вы не читатель?

В нормальных процессах все работает не так. Разработка сначала делается на бумаге, и только потом пишется код. При этом есть архитертор, который в теме. Так что 20 изменений делаются на бумаге и даже не в MVP.

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

Это товарища заклинило на гуях почему-то.

"Слышал? Лид-то нашего нового миддла на гуй послал. Сказал, нам в бекэнде такие косячники не нужны."

Крокодильчики у вас в голове.

Это у вас фиксация на том, что у меня фиксация только на GUI.

Я лишь сказал, что GUI тестирование это самое дорогое тестирование. И поэтому именно там нужно внедрять автоматизацию регрессионного тестирования.

А вы начинаете прибадываться к этому. И нести еще большую дичь, обзывая юнит тесты регрессионными. Хотя они к QA по сути не имеют отношения. Это инструмент разработчика

Дурачок, прости господи. Влез со своими воплями "регрессионные только на гуи уровне!" в обсуждение юнит-тестов, теперь сливается "GUI тестирование это самое дорогое тестирование. И поэтому именно там нужно внедрять автоматизацию регрессионного тестирования." Фу.

обзывая юнит тесты регрессионными. Хотя они к QA по сути не имеют отношения. Это инструмент разработчика

Спасибо, понял. На этом общение с вами заканчиваю, смысла нет.

Есть идеи как можно автоматизировать тесты без программирования и без Selenium , например возможно ли это делать в Jira Xray ? Или ещё какие либо идеи по автоматизации регрессионных тестов

Влез со своими воплями "регрессионные только на гуи уровне!" в обсуждение юнит-тестов,

лолшто? В исходном постинге идет речь о веб гуи тестах, а не о юнит тестах.

Щас глянул в недра одного самописного фреймворка а-ля ORM. Логирование на каждую операцию. Буквально вызвал функцию, залогировал - что вызвал, откуда и с какими параметрами. Создал объект - залогировал, что и как создал. Потом валидируешь этот объект - залогировал, что и как валидировал. Каждый лог это несколько строк данных. Примерно посчитал - на одну запись в БД штук 20 записей в лог. В одной большой таблице сотни миллионов записей. Логи там наверное на многие терабайты ушли за года эксплуатации.

Вопрос. А есть ли смысл в таких логах? Кто потом эти терабайты читает и разбирает? Софт был написан лет 15-17 назад, и такое ощущение, что по каким-то модным в то время практикам. По навороченности и сложности - какой-то космический корабль. Огромное число своих типов исключений, распределённые транзакции, свои самописные фреймворки для маппинга объектов, создания контролов на тогдашнем куцем HTML'е с поддержкой памяти состояния и прочего. Всё разнесено на разные части - сервер приложений, сервер сервисов, сервер для мобильного приложения, контракты контроллеры, воркфлоус, на любой класс заведён свой интерфейс, логирование через строчку, сбор всех возможных исключений, все возможные паттерны напиханы без меры. Даже простейшая операция - куча обращений между всеми этими частями с активным использованием COM+ и прочих межпроцессных взаимодействий. Но начнёшь вчитываться - какое-то огромное количество воды, многословность зашкаливает, а местами откровенно лишний код с проверками по несколько раз одного и того же. Такое ощущение, что архитектуру писал супергений, захотевший абстрагироваться вообще ото всех фреймворков на свете и всё сделать сам, а код - какие-то обезьяны. ))

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

А есть ли смысл

-----

Хи-хи...

Декомпельни любой мелкомягкий продукт и посмотри что там.

Если с декомпиляцией никак, то можешь поверить на слово - местами до 50% актуально-исполняемого кода занимаются именно измерением производительности и логированием.

Видимо по-другому уже никак не сбить рост производительности железа до приемлемого уровня.

Часто это не "коварство" программистов, подкупленных масонами. А таки требования заказчиков. Как только речь заходит о сервисе, разработанном для нескольких крупных клиентов, развоачиваются эпические срачи на тему "а почему мы платим 32,754% от текущих расходов, когда мы делаем только 25,72346% запросов к сервису? А давайте считать не по CPU Time а по количеству запросов?"

А логирование... Это ты для банков и страховок ничего не делал. Кое-где и операции чтения в лог уходят. И не забываем анонимизировать данные в логе. Но чтобы можно было со 100% точностью определить о каком клиенте речь. Но анонимно! Экономисты и юристы - такие лапочки...

до 50% актуально-исполняемого кода занимаются именно измерением производительности и логированием.

Если бы до 50%... Щас вытащил одну методину (method) в блокнотик, и стал удалять всё, что не делает собственно работу. Осталось из где-то 30 строчек лишь три: создать объект, присвоить значение, сохранить.

Ещё такая штука. Вот в этом многослойном приложении даже простая операция проходит через все эти контроллеры, потоки работ и прочее. Штук 20 вызовов функций. Это только в своём фреймворке и приложении, без учёта разных сторонних и уже написанных API. Каждая функция от 1 до 10 строк. Вроде всё по фен-шую, как дяди Бобы завещали, чтобы можно было легко отюниттестировать и всё такое. А потом, где-нибудь на низах, всё равно лапша на 100+ строк кода. И не какая-то банальная инициализация кучи свойство объекта, а именно много логики в одной функции. Зачастую идёт повтор того, что было сделано в предыдущей кучке вызовов. Такое ощущение, что кто писал первым, ещё как-то разбирался в этой "Звезде Смерти", а последующие челы делали уже лишь бы как-то работало, не в силах понять до конца, как вся эта каша из десятка слоёв функционирует. Не скажешь же начальству, что первые 3 месяца только знакомишься с исходниками, потом полгода пытаешься что-то делать, и лишь минимум через год-полтора перестаёшь вносить в репу новые баги. Куда там фикс старых и выкатка новых фич. Поэтому побыстрее херакс-херакс, и в отчётик начальству о свёрнутых горах.

Частое явление, да?

У нас сейчас есть актуальный кейс - проблема с БД. Создаем тикет у оракла и они (оракл) требуют Verbose лог с проблемой. Генерим лог, отправляем в оракл на анализ.

Собственно говоря, не просто так придуманы 1) уровни логгирования (error, warning, info, debug и еще куча кастомных уровней) и 2) не просто так придуманы циклические логи, сроки давности логов и ограничения по размеру логов.

Все это работает на то, чтобы получать нужную для исследования проблемы информацию. И да, если кто-то вместо уровня debug использует info, то он сам себе злобный буратино :)

А таки требования заказчиков.

-----

Гы... ну и какой заказчик, скажем, у компилятора Т4-шаблонов?

А между тем при переходе с версии на версию там не отличия от документации пофиксили, а впилили трекинг и логгинг...

Бля, Я вообще не говорю об том, чтобы дать инструмент для смены генерируемого кода... а надо, ой как надо...

У нас сейчас есть актуальный кейс - проблема с БД. Создаем тикет у оракла и они (оракл) требуют Verbose лог с проблемой. Генерим лог, отправляем в оракл на анализ.
Собственно говоря, не просто так придуманы 1) уровни логгирования (error, warning, info, debug и еще куча кастомных уровней) и 2) не просто так придуманы циклические логи, сроки давности логов и ограничения по размеру логов.
Все это работает на то, чтобы получать нужную для исследования проблемы информацию. И да, если кто-то вместо уровня debug использует info, то он сам себе злобный буратино :)

Это я всё понимаю. Не понимаю, стоит ли действительно писать так:

лог

валидатор входящих

лог

перформанс каунтер

лог

строчка кода

лог

валидатор предыдущей строчки кода

лог

ветвистая обработка исключений - по логу на каждую обработку

На одну строчку кода 20 строчек обслуги, не считая скобок. Функция занимает экран-полтора, хотя делают по сути одну операцию. И так в почти каждой функции. А функций может быть 10-20 друг друга вызывать. И когда знакомишься с таким кодом, долго думаешь, что тут происходит. И так трудно докопаться до сути, продравшись через дебри паттернов, так ещё у себя в голове и очистить всё от обслуживающей логики нужно.

Может, проще дамп памяти скинуть? Там как раз весь контекст. А читать все эти verbose - кто их будет?

Тоже мне бином Ньютона. Смортря чей компилятор. Микрософтовский, значит микрософт.

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

Может, проще дамп памяти скинуть?

Дамп памяти надо еще уметь анализировать. И нет, его скинуть не проще. Т.к. дамп - штука крупная и на каждую ошибку генерировать по дампу - очень накладно.

А читать все эти verbose - кто их будет?

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

Дамп памяти надо еще уметь анализировать.

Я думал, это такая штука, которую в какой-нибудь Студии открыл, а она тебе рраз - и открылся код, где возникает ошибка, с остановом на нужной строчке, и все данные в контексте всего стека вызовов, и по стеку гулять можно. Что, нету такого? А было бы удобно... Для суперсложных распределённых систем этого может быть недостаточно, но для основного большинства ошибок - вполне.

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

Вот тебе и записи в лог где можно и где нельзя.

------

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

Но лучший вариант все же был у меня.

У нас тогда пошли массовые проблемы с подключением к Ораклу... что-то работало, что-то отваливалось...

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

А потом был переход на постгрее и смена команды разработки... оставившей всю обработку оракловских ехсептионов...

Вопрос. А есть ли смысл в таких логах? Кто потом эти терабайты читает и разбирает?

Мальчик, или в школу. Там тебя научат делать ELK стек и анализировать логи с помощью ChatGPT

Зы. Ты случайно не писал систему логирования для ActiveMQ ? А то там ничего не логируется.

Логирование, это прямо какая-то чуждая кодированию вещь, требующая дофига обслуги, настроек и засоряющая код

Мальчик, тебе нужно в ясельную группу. На горшок.

Зы. Ты в курсе, что такое разделение ответственности в коже (code separation) ?

Выделяй inner helper class вызывай из него логируемый метод и добавляй столько логирования, сколько нужно.

А то развели тут клуб благородных девиц.

Может, проще дамп памяти скинуть?

Как можно можно лучше понять событие - увидев фотку или глянуть видео?

Особенно когда важно знать что за чем идёт.

Лучше дамп памяти со стеком вызовов и всем контекстом, и остановом в точке возникновения ошибки, чем какие-то тонны текстовых писулек.

Можно разделить как в логировании: уровень warning - небольшой дампчик ближнего окружения; уровень error - дамп побольше, окружение поширше; уровень fatal super-puper apocalypse - полный дамп приложения в RAM. Короче, настроить можно и по мере накопления статистики решить, насколько много дампить. Вобщем, всё как в текстовых логах, только без текстовых логов.

Я вообще поражаюсь, как люди любят занимать себя пустой работой, типа написания логов или тестов в объёме, на порядок превышающем сам код. Вместо того, чтобы придумать, как бы от работы освободиться и заняться любимым делом или предаваться ничегонеделанию. Лень - двигатель прогресса! А от работы и кони дохнут.

и остановом в точке возникновения ошибки

А кто интересно будет знать эту точку?

Я уже не говорю о том, что дапм памяти подразумевает немного другое.

или предаваться ничегонеделанию

вот именно от этого "нормальные" кони и дохнут

Не усложняйте.

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

Не то, чтобы такого нет :) Но, 1) создать минидамп - это дорого (это сотни мегабайт) 2) в студии дамп открыть можно, но для анализа дампа студии мало, нужны какие-то хардкорные приложения типа WinDbg 3) дамп без pdb файлов - мусор (ну если только ты не гуру ассемблера :), да и то не факт), а значит надо делать добавлять менеджмент pdb файлов.

Так что ниша дампов очень узкая. Это либо дэдлоки (тогда пользователь сам должен создать дамп) , либо это перехват исключения перед тем, как схлопнется приложение.

Чёт в голове крутится... Вот все говорят, я пишут мол сначала интерфейсы, а потом классы по ним. А не проще наоборот - сначала класс, а интерфейс из него одной командой вытаскивается? А вот наоборот нельзя - максмум по интерфейсу можно заготовку класса сделать.

Иногда бывает, что нет времени всё делать по фен-шую, писать тесты, интерфейсы и прочее - работать надо. А марафет потом как-нибудь наведём. И вот настаёт этот волнительный момент, когда можно расслабиться и пару дней пинать балду на расслабоне дописывать интерфейсы к классам, и тут разработчики IDE тебе подсирают - есть оказывается команда для извлечения интерфейса в пару кнопок. Предатели!

А не проще наоборот - сначала класс, а интерфейс из него одной командой вытаскивается?

Новечку, конечно, проще.

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

А марафет потом как-нибудь наведём.

Не наведешь :)

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

Во-вторых, код типа такого (все на классах)

public void Foo (DbConnection db, UserProvider provider)
{
    UserService srv = new UserService (db);
    
    User user = srv.GetUser (provider);
    if (user != null)
    {
        user.Login ();
    }
}

нетестируем и без рефакторинга тут уже ничего не сделаешь.

Всё легко и просто тестируется. Берёшь вместо реальной БД тестовую, которая может даже быть частичной копией реальной, и тестируешь прямо сам класс, а не кучку моков. Заодно и проблемы с тестовыми данными отпадают, которые что с вашими интерфейсами, что без, всё равно нужно откуда-то взять, как-то нагенерить.

Ещё такое мнение читал, что интерфейсы мол для быстрой замены реализаций. Как у вас в 95% случаев нет времени на рефакторинг, так и в 95% случаев никто реализацию потом не меняет. Вот в моём проекте 15-летней давности всё на интерфейсах, а UI как был из старинных времён, так его никто и не заменил. Как и вообще почти всё внутри. И сейчас логику просто переписываем с нуля, стараясь по возможности повторить её на новых версиях фреймворка, языка и вообще всего. А старые интерфейсы просто захламляли код.

Если надо что-то заменить, то обычно сначала отказываются от замены, потом опять отказываются, потом ещё раз отказываются, потом это всё работает уже лет 5-10, а потом просто переписывают. И снова 5-10 лет без замены. Спонтанные подмены СУБД, GUI и прочих вещей - это из феншуйских задвигов. В реальном кровавом энтерпрайзе всем этим на заморачиваются, а просто не трогают, пока оно работает и пока не припрёт. В моём проекте до сих пор бы не трогали, и жило бы всё и 20 лет, и дольше, но IE уже не поддерживается.

Ну во-первых, подсовывать под каждый тест реальную БД - это очень накладно. При этом не забываем, что тесты должны быть атомарными, т.е. независимыми друг от друга. Более или менее эффективно это может работать только с помощью собственного расширения для тестового фреймворка + работающая со снэпшотами БД (оракл или MS) + самописный UnitOfWork, который надо использовать как в расширении тестового фреймворка, так и в продуктивном коде. И даже в этом случае, производительность таких тестов будет желать лучшего. Я уж не говорю о том, что будут не юнит-тесты :D

Во-вторых, приведенный код нестестируем не столько из-за БД, сколько из-за new и из-за того, что UserService - реальный объект, а значит нельза мокнуть функцию GetUser. Которая, в свою очередь, тоже возвращает реальный объект, а значит нельзя проверить была ли вызвана функция Login :)

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

А не проще наоборот - сначала класс, а интерфейс из него одной командой вытаскивается?

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

что нет времени всё делать по фен-шую, писать тесты, интерфейсы и прочее - работать надо.

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

Всё, что делается по другому, со временем превращается в большую кучу мусора, как есть актуальный проект.

При этом, даже если делать все по правилам нет гарантии получения отличного кода.

Но переубеждать кого то в этом - бессмыслнная затея.

подмены СУБД, GUI и прочих вещей

-----

Если написано нормально, то любая из замен делается в пределах уровня без особых проблем.

значит нельза

-----

Мона. Надо сунуть имплементацию в дллку и подставить в тестах моку и все будет... :)

Так что лучше было бы сразу писать на абстракциях

------

Гы... а сразу - оно спагетти после 10-20 лет модификации фриками...

со временем превращается в большую кучу мусора

------

Оно всегда превращается в большую кучу мусора - по одной методике - раньше, по другой - позднее.

Главное в проекте - успеть спрыгнуть до того как выяснится что большая куча мусора уже образовалась.

А старые интерфейсы просто захламляли код.

А, ещё глянул, сколько же реализаций этих интерфейсов в проекте. В подавляющем большинстве случаев, да практически во всех - адын штука. Наличие этой тучи интерфейсов просто заставляет меня вместо f12 жать ctrl+f12 (я про Сишарп и Студию), чтобы сразу перейти к реализации. А ещё челы не освоили наследование комментов интерфейса реализацией, и писали в комментах к классам "смотри комменты интерфейса".

Более или менее эффективно это может работать только с помощью собственного расширения для тестового фреймворка + работающая со снэпшотами БД (оракл или MS) + самописный UnitOfWork, который надо использовать как в расширении тестового фреймворка, так и в продуктивном коде. И даже в этом случае, производительность таких тестов будет желать лучшего. Я уж не говорю о том, что будут не юнит-тесты :D

Просто юзаешь Entity Framework и всё. Там и юнит оф ворк, и прочее - всё встроено.

Во-вторых, приведенный код нестестируем не столько из-за БД, сколько из-за new и из-за того, что UserService - реальный объект, а значит нельза мокнуть функцию GetUser. Которая, в свою очередь, тоже возвращает реальный объект, а значит нельзя проверить была ли вызвана функция Login :)

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

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

При этом, даже если делать все по правилам нет гарантии получения отличного кода.

Вот в этом-то и проблема. Претензий у фен-шуистов дохрена, а гарантий - никаких. В чистом виде инфоцигане. Просто разные дяди Бобы получили сцену и широкую аудиторию, а вы нет. ))

Оно всегда превращается в большую кучу мусора

У меня есть несколько иной опыт Да, может быть сложно, да может быть поначалу непонятно,

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

Если же использовалась методика лишь бы как, то и понимание не приходит и менять что либо боишься.

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

подмены СУБД, GUI и прочих вещей

-----

Если написано нормально, то любая из замен делается в пределах уровня без особых проблем.

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

Главное в проекте - успеть спрыгнуть до того как выяснится что большая куча мусора уже образовалась.

Главное - продать проект с большой кучей мусора какому-нибудь крупному концерну за много денег. И уйти в закат, к домику у тёплого моря.

У меня есть несколько иной опыт

если проект постоянно делали "нормальные" прогеры

У вас сплошной положительный опыт. Скушно.

Вот в этом-то и проблема

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

Типа как товар из Китая, вроде всё и правильно, но в итоге часто недоволен.

У вас сплошной положительный опыт.

Кто сказал, что сплошной? Чаще всего сталкиваешься именно с проектами, где разработчиков правила не интересовали.

лучше тестировать на вещах, максимально приближенных к реальным

------

Неа...

максимально приближенные к реальному подделки

-----

Эээ... а зачем?

после этого уже ничего не запускается

-----

А должно?

Просто юзаешь Entity Framework и всё. Там и юнит оф ворк, и прочее - всё встроено.

Юнит оф ворк - это только одна из 3-х необходимых вещей. Как сделать остальные две? :)

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

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

Если вернуться к примеру:

public void Foo (DbConnection db, UserProvider provider)
{
    UserService srv = new UserService (db);
    
    User user = srv.GetUser (provider);
    if (user != null)
    {
        user.Login ();
    }
}

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

Если тестировать на объектах, то тест может стать крассным из-за ошибки в GetUser, а значит написанный тест тестирует все, что угодно, но только не фунцкцию Foo :)

Чаще всего сталкиваешься именно с проектами, где разработчиков правила не интересовали.

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

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

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

Зачем смотреть весь костюм? Ведь можно оценить по частям. К пуговицам претензии есть?

Мокаем отдельные части, мокаем части побольше, мокаем ещё побольше... И вот уже весь проект замочен в чём-то жидком и вонючем, не имеющим отношения к реальному окружению и ошибкам, в нём возникающим.

public void Foo (DbConnection db, UserProvider provider)
{
    UserService srv = new UserService (db);
    
    User user = srv.GetUser (provider);
    if (user != null)
    {
        user.Login ();
    }
}

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

Если тестировать на объектах, то тест может стать крассным из-за ошибки в GetUser, а значит написанный тест тестирует все, что угодно, но только не фунцкцию Foo :)

Правильный вызов логина на объекте юзер - прерогатива объекта юзер. Вот в юните для него пусть и тестируется. А так вы в любом месте вызова логина будете этот вызов тестировать? В пяти разных местах будет - в пяти местах будете тестировать, хотя вызов зависит лишь от объекта юзер, который находится в одном месте.

Разве юнит тесты не могут быть каскаднозависимыми? Т.е. не выполнились тесты на объектах в тестируемой функции, значит не выполнились тесты и на самой функции.

Если бы изолированные тесты с моками работали как в теории, то не нужны были бы интеграционные тесты, т.к. вы фактически тестируете интеграцию объекта user в функцию Foo. А раз у вас есть интеграционные тесты, значит вы не доверяете даже изолированным юнит тестам. Тогда смысл тестировать, если нижележащие объекты не проходят тесты? Вот когда начнут проходить, тогда и оттестируете. Нет никакого смысла в правильности функции Foo, если неправильны используемые ей объекты. А пока это получается самоуспокоение и лишняя работа - тестировать то, что потом всё равно будет перетестировано интеграцией. Может, вы хотите покрытие юнит тестами больше 100%? По-моему, это легко осуществить, продублировав все тесты по нескольку раз для разных мест.

Вообще, странно, что принципы программирования, а конкретно единственность ответственности, у вас легко нарушаются в тестировании, и вы ответственность одного объекта легко размазываете по всем другим местам, где этот объект используется.

У вас сплошной положительный опыт.

Кто сказал, что сплошной? Чаще всего сталкиваешься именно с проектами, где разработчиков правила не интересовали.

Следил за одним проектом в сети. С момента начала работ ещё до релиза. Челы получили некоторое финансирование от спонсора и года два времени на разработку. Делать надо было много и с нуля. Фигачили на результат, а не на будущую многолетнюю поддержку. Выкатили прототип, который уже на тестах пользователей взлетел. Так прототип в релиз и ушёл. И лишь отдав долги инвесторам и заработав самим, стали переписывать всё и покрывать тестами. Но ударились в другую крайность - гонку за феншуйством. Гордились, что покрытие тестами почти 100%, расширяемость неимоверная, проект на века, все дела. А потом пришли эффективные менеджеры по выжиманию бабла отовсюду, и вековой проект резко стал "ну протянем ещё несколько годиков". Полкоманды сменилось, пошли сокращения, челы почти забили на баги, а донатные хреновины сыпались одна за другой, продолжая убивать проект, но зато выжимая бабло из остатков пользователей. Но хозяева проекта бабла, конечно, подняли. Вот так и становятся семидевятизнаками - не по феншую.

Не стройте на века. Бесполезно и неблагодарно. Не сломается само, так сломают специально. Вообще разницы не вижу между чуваками, талдычащими про строгое придерживание кучи всяких солидов, интерфейсов и тестов, и тренерами личностного роста и успешного успеха. Та же хрень, только в профиль. Инфоциганам надо же что-то продавать - мечты об идеальном мире, программистские библии со своими десятью заповедями. А вы просто легко ведётесь на эту всю херню - ну чел же правильные вещи говорит! Мы пойдём за ним на край света!

лучше тестировать на вещах, максимально приближенных к реальным, а не всяких моках.

Заблуждение, которым я тоже иногда страдаю

Это будут уже не юнит тесты. Или вот например:

Нужно проверить отсылку почты при каких то условиях. Ваша реализация на реальных вещах?

А вот создать максимально приближенные к реальному подделки - тот ещё геморрой.

просто не нужно их создавать.

после этого уже ничего не запускается-----А должно?

Система запускается до изменений, но не запускается после? Првильная ситуация или нет?

Зачем смотреть весь костюм? Ведь можно оценить по частям. К пуговицам претензии есть?

Весь костюм смотрится на других этапах тестирования.

Значит, ваши теории "делай хорошо и не делай плохо" не работают.

откуда данный вывод? Люди просто не имели понятия о каких то теориях и писали как умели.

Но особого смысла в подобных дискуссиях не вижу. Человека не перетянуть из одной религии в другую насильно.

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

Не стройте на века. Бесполезно и неблагодарно.

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

Японцы полнейшие идиоты, зачем инвестировать столько времени и денег.

Следил за одним проектом в сети.

Я бы предложил сделать анализ успешных проектов...

Правильный вызов логина на объекте юзер - прерогатива объекта юзер. Вот в юните для него пусть и тестируется. А так вы в любом месте вызова логина будете этот вызов тестировать? В пяти разных местах будет - в пяти местах будете тестировать, хотя вызов зависит лишь от объекта юзер, который находится в одном месте.

Сначала надо ответить на вопрос "что мы тестируем". Если мы тестируем функцию Login, то unit under test - объект юзер. В данном случае unit under test - функция Foo и правильно ли работает объект User не имеет никакого значения, т.к. у Foo есть своя логика и именно ее мы тестируем.

Разве юнит тесты не могут быть каскаднозависимыми? Т.е. не выполнились тесты на объектах в тестируемой функции, значит не выполнились тесты и на самой функции.

Нет. Это уже будут не юнит-тесты. Юнит-тесты - атомарны и не должны зависить ни от каких других тестов или инфраструктуры.

Если бы изолированные тесты с моками работали как в теории, то не нужны были бы интеграционные тесты, т.к. вы фактически тестируете интеграцию объекта user в функцию Foo.

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

Когда я пришел на прошлый проект, там было около 30 интеграционных тестов, которые исполнялись около 2,5 часов. Я добавил в проект около 1000 юнит-тестов, которые выполнялись всегда вместе с компиляцией и требовали меньше 5 минут времени. При этом юнит-тестами можно покрыть гораздо больше тест-кейсов. Например, я в том проекте добавлял проверку на отказ в правах доступа жесткого диска. Сделать такое в интеграционном тесте очень сложно.

Вообще, странно, что принципы программирования, а конкретно единственность ответственности, у вас легко нарушаются в тестировании, и вы ответственность одного объекта легко размазываете по всем другим местам, где этот объект используется.

Это не так :)

Нужно проверить отсылку почты при каких то условиях. Ваша реализация на реальных вещах?

Я, в отилчии от некоторых сектантов, не придерживающих каких-то принципов 100%. Что нельзя тестировать на реальных вещах, то можно замокать. Но это будут в основном исключения для всяких взяимодействий со внешним миром. А вот БД можно использовать реальную. Точнее копию реальной, пусть даже не полную.

Следил за одним проектом в сети.

Я бы предложил сделать анализ успешных проектов...

Это очень успешный проект. Он очень сильно обогатил своих хозяев, о чём они раньше и мечтать не могли. И плюс они ещё его продали, перед тем, как выжать и привести в совсем ниспадающее состояние. Люди из обычных программистов стали долларовыми мультимиллионерами. Большинство других проектов куда хуже, хотя там поди многое пытались делать по феншую. Феншуйский код вообще с успехом проекта не только мало связан, но и зачастую идёт в разрез и препятствует развитию. Особенно поначалу.

Вообще, странно, что принципы программирования, а конкретно единственность ответственности, у вас легко нарушаются в тестировании, и вы ответственность одного объекта легко размазываете по всем другим местам, где этот объект используется.

Это не так :)

А чего вы боитесь признаться, что это таки так? Можно сказать, что тестирование это не программирование, потому имеет право на другие принципы и подходы, хотя и там и там код. Ну как верстание страничек не программирование, хотя в вёрстке тоже код.

А вот БД можно использовать реальную

Ок, есть у нас 5 программистов работающих над одной задачей и Оракле база.

Как будем всё делить? При это тестов хотя бы 50 и для каждого теста нужно иметь исходное состояние

Это очень успешный проект. Он очень сильно обогатил своих хозяев

Упс,.. у нас разные критерии успешности проектов

Ок, есть у нас 5 программистов работающих над одной задачей и Оракле база.

Он не знает. Он с таким не работал.

А вот БД можно использовать реальную

Ок, есть у нас 5 программистов работающих над одной задачей и Оракле база.
Как будем всё делить? При это тестов хотя бы 50 и для каждого теста нужно иметь исходное состояние

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

Или можно для каждого типа тестов всегда держать слепок, который будет копироваться пре прогоне тестов. А сам слепок - периодически обновляться данными из реальной БД. Всё лучше, чем ваши 50 кейсиков вручную набивать.

Это очень успешный проект. Он очень сильно обогатил своих хозяев

Упс,.. у нас разные критерии успешности проектов

Деньги всему голова. "Если такой умный, почему не богатый?" - умный человек сказал, то есть богатый.

Првильная ситуация или нет?

-----

Конечно правильная.

Ну прикинь - заменил винду на РТОС и вопрошаешь свой вопрос?

А проблема... Блин, сколько раз Я чистил разные кеши от версий дллок...

В тесте скрипт создаёт слепок нужной части БД.

-----

Теперь запусти это все в параллели и, желательно, с разных машин.

Ты же за реальный мир - пусть изначально конкурируют как юзеры.

Когда победишь - тебе будет предложено вместо выделенной тестовой

базы пользоваться живой производственной.

Ну нету другой и железа под нее нету...

В тесте скрипт создаёт слепок нужной части БД

Вопрос был не про это. Как нам разделить базу на х "человек" одновременно. При этом х меняется.

Хотя создание и удаление "слепков" для х тестов тоже интересная задача.

А то что тесты могут исполнятся параллельно, где то еще учитывется?

Деньги всему голова.

Ну прикинь - заменил винду на РТОС и вопрошаешь свой вопрос?

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

Никаких кэшей и прочего..., дополнительно не имеется.

В тесте скрипт создаёт слепок нужной части БД.

-----

Теперь запусти это все в параллели и, желательно, с разных машин.

Ты же за реальный мир - пусть изначально конкурируют как юзеры.

Конкуренция и прочее отрабатывается в самой СУБД, которую тестировать не надо - за вас это уже сделали. А если сама ваша функция должна работать в многопоточном конкурентном окружении, тогда да - надо тестировать.

Как, кстати, на юнит тестах тестируется работа в многопоточке?

Когда победишь - тебе будет предложено вместо выделенной тестовой

базы пользоваться живой производственной.

Ну нету другой и железа под нее нету...

Когда чего-то нету, тогда и действуем соответственно. Но в пределе, из говна конфетку не сделаешь. Но можно побрызгать ароматизатором и обернуть в красивый фантик.

Вот Алекснек не хочет рассуждать, когда чего-то нету или не по правилам. Всё должно быть по феншую, а то он не играет. ))

Вопрос был не про это. Как нам разделить базу на х "человек" одновременно. При этом х меняется.

Хотя создание и удаление "слепков" для х тестов тоже интересная задача.

А то что тесты могут исполнятся параллельно, где то еще учитывется?

Для сложных и запутанных случаев я готов сделать исключение - пишите ваши моки.

Для сложных и запутанных случаев я готов сделать исключение

Это не сложный и запутанный случай - это обычная работа в команде.

Есть просто определенные требования к юнит тестам в этих случаях, типа:

- они должны запускаться в любом окружении, как на твоем компе так и на сервере

- тестам должно быть без разницы как они запускаются и в каком порядке (Обычно NUnit это не любит)

не хочет рассуждать, когда чего-то нету или не по правилам

Не совсем верно, рассуждать всегда можно. Только правила дорожного движения всё-таки соблюдать следует

окружение не меняется

------

Да ну?..

окружение не меняется------Да ну?..

что то я батенька не понимаю в какую сторону вы гоните.

Пример был описан, зачем еще что то придумывать?

Берём исходных код - работает, берем новый код не работает, возвращаем все изменения назад - работает.

Где проблема?

Где проблема?

------

Ну как тебе по проще объяснить...

Вот есть лопата и есть снег - берешь лопату и кидаешь снег... Все работает.

Теперь меняешь лопату на вилы и... правильно - ничего не работает...

теперь меняешь лопату на вилы и... правильно - ничего не работает..

С какого бодуна тебе такое мерещится? имя namespace должно иметь катастрофические последствия для работы программы?

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

-----

А почему нет?

У меня полно кода который имеет очень позднее связывание, в том числе по аттрибутам, а там полные имена (с неймеспэйсами) классов обязательны.

Ну или почти все связанное с рефлекшен обязано ломаться.

У меня полно кода который имеет... обязано ломаться

И это считается нормальной и распространённой ситуацией?

А почему нет? Оно же изначально заложено в систему...

А почему нет?

Зачем мне нужна программа в которой ничего нельзя переименовать?

Всего-то один раз подобная фигня и встретилась.

Зачем мне нужна программа в которой ничего нельзя переименовать?

------

Не знаю.

Ты же зачем-то имеешь проблему с отказом при переименовании...

Ты же зачем-то имеешь проблему с отказом при переименовании...

имел... и это всего то иллюстрация, что может получится когда плюют на правила.

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

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

С текстовым анализатором всё в порядке. Поиск работает как надо. Невозможность искать товары не на своём языке в своём регионе - так и было задумано. Как и две учётки по разным углам экрана. Как и надпись "media is too big to download" даже для маленьких видосов, хотя в мануале сказано, что "от 2 гигабайт". Просто не все сразу догоняют, кому и зачем это выгодно.

Почитал там статью:

Rate Limiter

Расширение API

Метрики latency

Граф вычислений

Микрооптимизации

Type pollution

ANN и Panama

Unsafe mmap

И прочая мудрёная параша, тянущая на докторскую диссертацию. Выдрачиваешь такой оптимизацию, а потом приходит менеджер, кидает на стол срочный фикс к ТЗ, и говорит, что первые 10 результатов должны браться вот из этой таблички с нашими спонсорами. Ну и хули ты тут оптимизировал, если на первой странице надо показать просто рекламу, а на второй и дальше твои оптимизации уже не нужны? Эти "специалисты", пишущие подобные статейки, просто дрочат на своё резюме, чтобы можно было написать в нём, что делал чуть ли не "звезду смерти". А в реале бизнесу почти плевать на всю эту херню - яйцеголовые развлекаются там в своём мирке, ну и хрен с ними. Наше дело - тянуть баблинский со спонсоров и рекламодателей, а для этого диссертации писать не нужно.

Нужно "графин стеклянный 2 литра".

Получаешь "кувшин пластиковый 1 литр" и пачку рекламы вообще не про графины, стекло или литры.

Просто сейчас очень нужно продать горные велосипеды. Когда нужно будет продать городские, тогда и приходите.

- Есть набор гаечных ключей?

- Вот очень хорошие шерстяные носки. Только сегодня и только для вас скидка 30%, если возьмёте сразу 3 пары!

Я понимаю, когда такое говорит "эээ, слющай, дарахой" на толкучке. Ну, я туда больше не хожу. А когда солидные дяди, учащие тебя со сцены как писать код и вообще жить, действуют точно так же...

Вы спросите, как это всё относится к автоматизации тестирования? А я чем хуже мэтров разработки с семизначными зарплатами?