Software Architect
Что делать, если никто не хочет документировать? Организация документирования микросервисов по минимуму
Представьте что у вас команда специалистов, которая по принципу code-first делает систему с множеством бизнес-историй на базе микросервисов. Все люди опытные, всем есть что делать кроме того как писать документации или спецификации на разработанный API. И все изначально знают, что если захотел использовать какой сервис, то надо заглянуть в код и потом спросить в общем чате если что непонятно. Знакомая ситуация не так ли? -))) И в целом все нормально, если бы со временем не росла команда, не росло количество сервисов и функций, не появлялись баги от бизнеса и тестеров, не требовалось предоставлять API для интеграции смежным командам...
Эта статья, на момент написания, является моим личным мнением о минимальной структуре документирования микросервисов в условиях его отсутствия. Личное мнение родилось в ходе мозгового штурма реальной ситуации и поисков повышения качества в разработке среднего по масштабу бизнес приложения.
Как получить OpenID/OAuth2 токен для тестирования front-end rest сервисов?
Вопрос — как его взять? И так это сделать красиво и правильно? Вот тут я не знаю.
В этой статье я описал то быстрое решение к которому я пришел и которое мне не вполне нравится. Выглядит костыльным, хотя я и не нагуглил ничего серебряного. Поэтому, если вы знаете лучшее решение — обязательно скажите об этом в комментарии… Итак…
Есть обычная типовая система с веб рест фронтом и типовым Single-Page-Application браузерным клиентом на JS. Аутентификация и авторизация — KeyCloak с Authorization Code Grant + brokering.
Надо обеспечить регулярное нагрузочное тестирование фронтовых рест сервисов.
Реализация процесса выгрузки файла из контейнера с браузером в тестовый фреймворк
Автоматизация End-2-End тестирования комплексной информационной системы
Часть 2-2. Реализация процесса выгрузки файла из контейнера с браузером в тестовый фреймворк. Поиск имени загруженного браузером файла
Автор: habr.com/ru/users/anrad
Хабы:
Теги: #autotest, #selenium, #selenoid, #headlessbrowser, #download
Когда мы в разработке End-2-End автотестов для UI столкнулись с вопросом “Как получить имя последнего загруженного браузером файла из WebDriver?”, нагуглить ничего по-быстрому не получилось. Поэтому я и написал эту статью, в которой заодно рассказал, в чем именно у нас была проблема и как мы ее решили.
Этой статьей мы продолжаем серию публикаций о том, как мы автоматизировали в одном из крупных проектов ЛАНИТ процесс ручного тестирования (далее – автотесты) большой информационной системы (далее – Системы) и что у нас из этого вышло.
source
Как сделать базовый тест-класс для Selenium тестов и выполнить инициализацию через JUnit RuleChain
Как эффективно организовать иерархию классов? Как распределить пакеты по проектному дереву? Как сделать так, чтобы забыть о мердж-конфликтах при команде в 10 человек? Эти вопросы всегда стоят при старте новой разработки и на них никогда не хватает времени.
Источник
В этой статье мы описываем структуру классов и организацию кода, которая позволила нам небольшими силами разработать более полутора тысяч end-2-end UI тестов на базе Junit и Selenium для крупной системы федерального значения. Более того, мы ее успешно поддерживаем и постоянно дорабатываем существующие сценарии.
Здесь вы сможете найти практическое описание структуры иерархии базовых классов автотестов, разбиения проекта по функциональной модели java-packages и шаблоны-образцы реальных классов.
Статья будет полезна всем разработчикам, которые разрабатывают автотесты на базе Selenium.
Автоматизация End-2-End тестирования комплексной информационной системы. Часть 2. Техническая
Вторая часть публикации ориентирована в первую очередь на лидеров групп автоматизации UI end-2-end тестирования и ведущих тест-автоматизаторов. Здесь они найдут конкретные рецепты по архитектурной организации кода и развертывания, которая поддерживает массо-параллельную разработку больших групп тестов в условиях постоянной изменчивости тестовых спецификаций. В этой части приведен полный состав необходимых для UI-тестов функций с некоторыми деталями реализации, а также есть перечень сюрпризов, с которыми вы можете столкнуться.
Вот здесь вы найдете Часть 1. (Зачем нам была нужна автоматизация. Организация процесса разработки и управления. Организация использования)
Источник
Автоматизация End-2-End тестирования комплексной информационной системы. Часть 1. Организационная
Первая часть – организационно-управленческая – должна быть полезна в первую очередь тем, кто отвечает за автоматизацию тестирования и создает такие системы в целом. Руководители проектов, лидеры групп и владельцы сервисов функционального и автоматического тестирования, все, кого волнует вопрос «как построить экономически эффективное end-2-end тестирование своей ИТ системы», найдут здесь конкретный план и методику.
Источник
Информация
- В рейтинге
- Не участвует
- Откуда
- Wien, Wien, Австрия
- Дата рождения
- Зарегистрирован
- Активность