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

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

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

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

Теплее.

Папка \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-тестирования инструмент, где я мог бы записывать последовательность действий(мышь+клавиатура) примерно как в мс офис запись макросов.

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