Home

Автор: Энди Найт (Andy Knignt)
Оригинал статьи
Перевод: Ольга Алифанова

Разработка через реализацию поведения (BDD) может помочь команде создавать хорошее ПО через скрупулезную спецификацию поведения продукта на простом языке. Неважно, хотите ли вы улучшить сотрудничество через встречу "трех друзей", или повысить качество автоматизации при помощи фреймворка вроде Cucumber – в центре BDD стоит один язык: Gherkin.

С первого взгляда Gherkin выглядит простым – просто напишите ряд шагов, описывающих желаемое поведение. Однако я сталкивался с командами, которым очень трудно хорошо писать на Gherkin. Начинающие часто страдают от писательского ступора, или же пишут сценарии, которые сложно автоматизировать. Иногда противоречивость заставляет людей по-разному интерпретировать шаги. Еще, бывает, люди слишком детализируют шаги, делая сценарии сложными для понимания. Раздражение от Gherkin даже выливается в плохую репутацию BDD.

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

Оригинальная публикация
Автор: Ксения Якиль

Привет! Меня зовут Ксения Якиль. Я пишу core-сервисы на C и Go в бэкенд-отделе Badoo и Bumble. Наш бэкенд — это высоконагруженная распределённая система, обслуживающая пользователей по всему миру. Она оперирует большими массивами данных и делает всю ту магию, благодаря которой люди находят друг друга. 

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

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Современные команды разработки ПО размывают традиционные границы между разработчиком и тестировщиком. Это означает, что разработчики все сильнее вовлекаются в тест-автоматизацию на всех уровнях пирамиды, а тестировщики все глубже погружаются во внутреннюю механику приложения. Разве не здорово бы было найти причины багов JavaScript, а не просто сообщать о них? Это можно сделать при помощи брейкпойнтов инструментов разработчика Chrome!

В этой статье я шаг за шагом проведу вас по использованию Chrome Dev Tools для дебага. Я узнала об этом из этой полезной статьи в блоге Google, но я буду использовать пример приложения, чтобы вы смогли попробовать различные методы самостоятельно.

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

Оригинальная публикация
Автор: Евгения Шереметова (телеграмм канал автора @bel-qa)

Фреймворк Cucumber используют как часть bdd-подхода к разработке, так и как отдельный инструмент для автотестов. 40+ млн скачиваний обеспечили фреймворку богатый опыт использования, но актуализировали поверхностное отношение к этому инструменту. Разбираем популярные огуречные антипаттерны и учимся писать действительно выразительные сценарии.

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

Статья взята из блога компании «НТЦ ПРОТЕЙ»

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

Меня зовут Диана, я руководитель группы тестирования пользовательских интерфейсов, автоматизирую веб и десктоп тесты уже пять лет. Примеры кода будут на java и для web, но, на практике проверено, подходы применимы и к питону с десктопом.

Автор: Алан Ричардсон (Alan Richardson)
Оригинал статьи
Перевод: Ольга Алифанова

Краткое содержание: в мире множество хороших ресурсов для изучения JavaScript. Вам не нужно устанавливать IDE, вы можете научиться JS в консоли.

Для чего нужно учить JavaScript?

• Тестируя веб-приложение, вы можете смотреть на код.
• Для понимания кода.
• Для понимания ошибок в консоли разработчика.
• Для поиска обходных путей через дефекты приложения.
• Для автоматизации в браузере.
• Для создания вспомогательных инструментов вроде BookMarklets.
• Для улучшения использования WebDriver JavascriptExecutor.
• Для странных и загадочных открытый, которые вас поразят, когда вы выучите JavaScript.

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

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

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

В этой короткой серии статей я исследую библиотеку Python requests и ее использование для тестов REST API. Это четвертая статья в серии, и в ней мы разберемся с имитацией ответов для юнит-тестирования.

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

Если вы пишете тесты Selenium на C#, то, возможно, заметили, что начиная с версии 3.11 ряд часто используемых штук помечен как устаревший – в частности, PageFactory и класс ExpectedConditions. Для тех, кто не знает, почему это произошло – вот объяснение Джима Эванса, основного разработчика связки Selenium C#.

Все это перемещено в новое место и доступно в форме отдельных пакетов NuGet (DotNetSeleniumExtras.PageObjects и DotNetSeleniumExtras.WaitHelpers, соответственно). Когда я писал эту статью, этот репозиторий никто не поддерживал – а следовательно, поддержка недоступна, и будущее его туманно.

Автор: Рене Муландари

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

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

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

Недавно я смотрел вебинар "Убивает ли Cucumber-автоматизация ваш проект" от SauceLabs, представленный Николаем Адволодкиным. В этом вебинаре Николай демонстрировал интересные цифры: 68% опрошенных сообщали, что они не сотрудничают с коллегами, создавая спецификации на сессии "трех товарищей". Однако 54% опрошенных сказали, что пользуются Cucumber.

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