Home

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

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

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

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

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В предыдущих статьях серии о тестировании ориентированных на потребителя контрактов и Pact мы обсуждали CDCT, разобрались, как использовать Pact для поддержки CDCT, как автоматизировать процесс и сделать его частью процессов CI/CD, и посмотрели, что будет, когда на стороне потребителя меняются ожидания.

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

Предупреждение: двусторонне направленное тестирование контрактов существует только в Pactflow и недоступно в OSS Pact Broker.

Автор: Теодор Жеррад (Theodore Gerrad)
Оригинал статьи
Перевод: Ольга Алифанова

Если вы интересуетесь тест-автоматизацией, то в какой-то момент зададитесь одним (или всеми) из следующих вопросов – что такое Page Object Model (POM)? Важна ли тест-автоматизация? Надо ли этому учиться? Сколько времени это обучение займет? Если вы похожи на меня – а вы, скорее всего, похожи – то вы впадете в панику, быстро и последовательно спрашивая себя обо всем этом. Хоть я и не эксперт (пока что), я могу предложить свой взгляд на эту проблему. Хоть я и не могу явно ответить на все эти вопросы, я хотел бы поделиться рядом мыслей в этой статье.

Привет, я Black из Scalable, QA Lead в команде бэкенда по разработке биржевого ядра. Так как уже долгое время занимаюсь развитием высоконагруженной платформы, решил написать о том, как нам удалось поставить QA-процесс с 20 000 тест-кейсов, создать гибкую инфраструктуру для автоматизированного тестирования в нескольких типах API, включая асинхронные бинарные протоколы, и пройти путь разработки от отладочных утилит до специализированных тестовых фреймворков для интеграционного и компонентного тестирования. 

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В предыдущей статье мы остановились на том, что у нас все в порядке с интеграционным тестированием: провайдер Address способен удовлетворить ожидания потребителей Customer и Order. Затем мы успешно справились с автоматизацией генерации контрактов и их публикации. Мы также автоматизировали их загрузку, проверку и публикацию результатов верификации на стороне провайдера.

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

Автор: Рубанов Михаил

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

За этим мнением скрывается простая правда — люди, которые так говорят, не умеют писать тесты. Не умеют писать их быстро; писать там, где нужно; писать так, чтобы была ощутимая польза для бизнеса. Я тоже был таким — понимал, что тесты нужны, но не понимал какие, где и как их писать. 

Рассказываю, что поменялось спустя 2 года и 4 тысячи тестов.

Автор: Павел Новиков, QA Engineer

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

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

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В третьей части этой серии статей мы разобрались, как создавать тесты контрактов, ориентированных на потребителя, для наших потребителей Customer и Order и провайдера Address, с целью выявить потенциальные проблемы интеграции. Процесс генерации и распределения контрактов на стороне потребителя, а также получения и верификации их на стороне провайдера, все еще содержит приличное количество шагов, выполняемых вручную. Что еще хуже, у нас нет способа закрыть петлю обратной связи – мы никак не можем сообщить всем заинтересованным сторонам результаты верификации контракта провайдером.

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

Автор: Руслан Ахметзянов, Qameta Software

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

А ведь десять лет назад релизы происходили раз в месяц, если не реже. Ускорение релизного цикла в сотни раз стало возможным благодаря десяткам новых инструментов и подходов в разработке и эксплуатации. Ломающий барьеры DevOps с облаками, CI/CD системами, контейнерами и мониторингами и рассчитанный на максимальный фокус и скорость Agile применяют (с переменным успехом) порядка 80% IT-компаний.

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