от. дані потрібно готувати динамічно для тесту. і видаляти після

з поглибленим вивченням німецької мови. Статистика не була окремим предметом, але була в курсі алгебри

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

ваш тест стає недермінованим. Напишіть тест, де це вікно ТОЧНО з’являється або не з’являється

Где ж я ещё спрошу, как не тут?!?

в гугла наприклад. Це просте питання, яке доречі покривається шкільним курсом статистики.
На банальні питання ніхто не хоче відповідати

курсы

для архитектора

JS

так собі ембеддед з ардуїно та малинкою...

моноліт — гімно
мікросервіси — гімно
serverless — гімно
soa — гімно

не хочу тягнути з registry та запускати локально всі мікросервіси. Роблю і плачу

угу. плачете, коли витрачаєте 10хв часу на тестування локально, але витрачаєте час на деплой, прогон повільних тестів і логування дефекту. Це буде точно довше ніж локальне тестування

вважаю, що тестування в готовому енвайрменті (production like) дає більш правдиві результати.

в вас ні разу не було такого, що unit, integration, api тести пройшли, а користувачы з продакшену баг заводять? Без UI тестів в складних системах ніяк

не плутайте мухи та котлети. Рівні тестування покликані вирішити різні проблеми. Те, що може виловити UI тест, може не знайти unit тест. але це не означає, що повинен бути лише один рівень тестів. Кожен рівень тестів знаходить різні проблеми. І те, що юзер знаходить дефект, після того як юніт тести пройшли, говорить не про те, що unit тести погані.

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

зіткнулись з такою проблемою. Тому більше націлені на тести на рівні сервісу

А точно ли это нужно?

що саме : спускатись на нижні рівні чи тестувати взагалі ?
якщо спускатись на нижчі рівні — то, так треба. і не одним юніт тестінгом. треба щось між юніт та API рівнем : контракти, сервісні тести, інтеграційні
якщо про тестування взагалі — то взалежності, які цілі переслідуєте. без тестування, пізніше може бути дорожче

Мікросервіси складно тестувати атомарно

в чому проблема підняти їх та тестувати на пряму ? це одна з переваг

Мікросервіси можуть використовувати різні канали зв’язку.

а в чому проблема використовувати різні канали зв’язку ? я певен, що є готові реалізації і для tcp і для RabbitMq і для будь чого іншого

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

Поради для девів також підійдуть. Я з будь яких порад черпаю досвід.
На рахунок дупи. Ну якщо ти вважаєш, що я в дупі це твоя думка. Я не бачу проблем у своїй кар’єрі, пропозицій та оферів достатньо.
Просто не бачу розвиток у вивченні нового фремворка чи була. Якщо це потрібно для проекту — це без проблем. А просто це приносить мало сенсу.
Тому мені цікаво як до цього підходять інші

Я не в дупі. ЗП не маленька, знайти роботу не складає проблеми. Перспективи qa це йти в менеджери, чого я не хочу на даний момент. Йти в девелопмент — для мене це не проблема, якщо говорити про .net . Хіба досвіду мало, але я не бачу це як розвиток, це швидше зміна напрямку.
От власне цікавить рух на межі компетенцій. І цікаво почути як інші це роблять

власне. саме це і було поштовхом до теми.

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

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

от цікаво які рівні є в лідерів ринку і як ростуть у них

Research new tools

я дослідив і спробував багато фреймворків та тулів. Звісно, я не експерт у них, але якщо потрібно завтра писати на новому фреймворку чи новій мові — розберусь за короткий час. Що міг застосував на своїх проектах. Інші або не підходять, або використовуються аналоги

допомога колегам в технічному розвитку

допомагаю з цим колегам, але якось ТЕХНІЧНОГО розвитку воно мені не приность

виглядає за дуже загальна тема

можливо, не знав як краще оформити свої думки

окай. може. а як визначити чи я сіньйор-помідор чи ще ні ?

1. Автоматизацій

4. Секюріті-спеціаліст який небудь

власне, як AQA\QA багато чого пройдено.
питання вивчення нового фреймворка не стоїть, щоб розібратись з новим фреймворком чи іншим тулом треба 2 дні і можна працювати.

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