Home

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

Обзор

unittest – это стандартный Python-фреймворк для юнит-тестов. Создатели вдохновлялись JUnit, и он включается в стандартный дистрибутив CPython. unittest содержит базовый класс TestCase, дающий методы для утверждений и рутин настройки и очистки. Все классы тест-кейсов должны наследоваться от TestCase. Каждый метод в подклассе TestCase, чье имя начинается с "test", будет прогоняться как тест-кейс. Тесты можно группировать и загружать с использованием класса TestSuite и методов загрузки – используя их совместно, можно создавать свои собственные тест-загрузчики. unittest также может генерировать XML-отчеты (как и JUnit), используя unittest-xml-reporting.

unittest поддерживается и в Python 2, и в Python 3. Однако для версий старше Python 2.7 нужно пользоваться портированием unittest2.

Автор: Бет Маршалл (Beth Marshall)
Оригинал статьи
Перевод: Ольга Алифанова

• Язык: VB.Net / UiPath
• IDE: UiPath Studio
• Инструмент управления исходным кодом: Github через Github Desktop
• Тип тестов: UiPath
• Тестируемый сайт: сайт моего спортзала

В этой статье я бы хотела поговорить про свой опыт создания тест-фреймворка роботизированной автоматизации процессов (RPA) с использованием ведущего поставщика на рынке UiPath.

Я познакомилась с UiPath в этом году, когда одной из первых сдавала их новый базовый экзамен – UiRPAv1. Я официально сертифицирована, но почти не работала с этим инструментом после сдачи экзамена, поэтому это показалось хорошей идеей для обучения на ходу.

Я очень довольна тем, как продвигается работа над моим портфолио, учитывая, с чего я начинала, но не думайте, что этот код занял у меня пару минут. Я потратила несколько дней, и много времени ушло на Google. Но все мы с чего-то начинаем, и я уверена, что кривая обучения ускорит работу в следующий раз. Еще один дополнительный бонус – симпатичный шаблон, с которого я смогу начать в следующий раз.

Автор: Дейв Вестервельд (DaveWesterveld)
Оригинал статьи
Перевод: Ольга Алифанова

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

Но.

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

Автор: Виктор Славчев (Viktor Slavchev)
Оригинал статьи
Перевод: Ольга Алифанова

К статьям вроде "Принцип трех А" я часто получаю комментарии вроде таких: "у нас проблемы с пересечением пользовательских данных в тестах", или "как бы вы управились с Х тестами, каждому из которых нужно наполнение данными".

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

Автор: компания Simbirsoft

Ранее мы уже писали о том, когда бывает нужна автоматизация тестирования и какие проверки при этом используют. Сегодня предлагаем обсудить использование инструментов на практике и оценить их производительность. С разрешения Giovanni Rago – автора серии полезных материалов о тестировании – мы перевели его статью «Puppeteer vs Selenium vs Playwright: сравнение скорости» (Puppeteer vs Selenium vs Playwright, a speed comparison). Статья будет интересна тем, кто задумывается о выборе подходящего инструмента автоматизации в своих проектах.

Автор: Ольга Назина (Киселёва)

Введение

Сегодня я расскажу про плагины браузера, которые помогают быстро заполнить поля тестируемой формы. Рассказ также доступен в виде видео. Мой топ-3:

• 3 место — Bug magnet

  • О плагине

  • Как использовать

  • Плюсы

  • Минусы

• 2 место — Web developer toolbar

  • О плагине

  • Как использовать

  • Плюсы

  • Минусы

• 1 место — Fake Filler

  • О плагине

  • Как использовать

  • Плюсы

  • Минусы

• Итого

Применять плагины мы будем на бесплатной системе Users. 

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

Python – потрясающий язык программирования. Его любят и новички, и эксперты, и он регулярно оценивается как язык с самым высоким спросом. На конференции PyData Carolinas 2016 Джош Хоус, старший менеджер управления данными в MaxPoint, описал Python примерно так:

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

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

Автор: Пол Гриззаффи (PaulGrizzaffi)
Оригинал статьи
Перевод: ОльгаАлифанова

Вперед, к поиску по сети! В ней больше постов и статей про "десять заповедей тест-автоматизации", чем вы кейсов в жизни написали. Вперед! Я подожду.

Добро пожаловать назад!

Внесу ясность – я не читал ни одну из этих статей. Точнее, недавно я не читал ни одной из них, а большую часть не читал никогда. Возможно, я просматривал одну или две давным-давно, но не могу вспомнить ни одной конкретной заповедей. Все то, что я еще не знал и счел разумным, я, скорее всего, давным-давно применил в своей практике. Говорю это не чтобы принизить другие статьи, а чтобы сослаться на них в том высоко вероятном случае, если некоторые из моих "заповедей" уже озвучивались до меня; я не копировал чужое, и если я повторяюсь, то надеюсь улучшить их. Я также хочу поделиться идеями, о которых вы раньше не задумывались.

Поэтому я не пишу о "ДЕСЯТИ заповедях тест-автоматизации". Вместо этого я расскажу о ЕЩЕ десяти заповедях тест-автоматизации. Поехали!

Автор: Даниил Тимашов
Оригинальная публикация

Привет, Хабр. Я работаю QA Automation инженером в компании Wrike и хотел бы поговорить о том, как нам удалось оптимизировать процесс код-ревью для репозитория с 30 000+ автотестов при помощи IntelliJ IDEA плагина. Я расскажу о внутреннем устройстве плагина и о том, какие проблемы он решает в нашей компании. А еще в конце статьи будет ссылка на Github репозиторий с кодом плагина, с помощью которого вы сможете попробовать встроить плагин в ваши процессы.

Автор: Тоби Стид (TobySteed)
Оригинал статьи
Перевод: Ольга Алифанова

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

К сожалению, такие компании – редкость, поэтому, обнаружив себя в такой ситуации, легко испытать головокружение от всего, что вы хотите сделать и чего достичь. Однако куда меньшая редкость – это в один прекрасный день открыть бэклог или доску JIRA (или того инструмента, которым вы пользуетесь), и увидеть, что все сложности по запуску новой тест-автоматизации, все ее проблемы и задачи дистиллированы в один-единственный тикет – зачастую с расплывчатым именем вроде "Создание автотестов".