Модульное тестирование (unit testing) применяется повсеместно. Кажется, уже никто без него не обходится, все пишут тесты, а их отсутствие в сколь-нибудь серьёзном проекте вызывает, как минимум, непонимание. Однако, многие воспринимают тестирование как некий ритуал, совершаемый для того, чтобы не разгневать "бога программирования". Мол, так надо. Почему? Потому что.
Буду говорить страшные вещи.
Не важно, что брать за единицу тестирования. Не важно, как сгруппированы тесты. Не важно, пишутся ли они до кода или после. TDD или не TDD? Всё равно. Доля покрытия? Наплевать. В конце концов, тестов может совсем не быть. Всё это совершенно не важно. Важно, чтобы выполнялись требования, предъявляемые к ПО.
Модульные тесты — это не ритуал, а хороший, рабочий инструмент, позволяющий приблизиться к выполнению этих требований. И этот инструмент нужно уметь правильно использовать.
Автор: Жданов Илья Владимирович, ЛАНИТ, Тест-менеджер (15 лет в IT, за первые 10 лет прошел путь от эникейщика до руководителя направления системных аналитиков, последние 5 лет занимаюсь созданием команд и практик по тестированию на проектах от 5 до 60 QA)
В последнее время автоматизацию тестирования называют «серебряной пулей» от всех проблем проекта. Многие приступают к автоматизации очень спонтанно и лайтово, не просчитав все «за» и «против», плюсы и минусы, сопровождение и окупаемость.
А вообще автоматизация тестирования – очень дорогой и специфический инструмент. Поэтому к ней нужно подходить с должным уровнем зрелости кода и самого проекта. Иначе можно потратить миллионы часов и денег, а эффект получить микроскопический или не получить его вообще.
В этой статье я постарался:
осветить «детские болячки» тест-менеджмента, стремящегося автоматизировать все, что не приколочено,
пояснить, какую пользу может нанести бюджету проекта автоматизация тестирования без детального анализа ее скоупа и должной подготовки,
составить Roadmap для подготовки к автоматизации проекта.
Автор: Баз Джикстра (Bas Dijkstra) Оригинал статьи Перевод: Ольга Алифанова
Ранее я приводил примеры базовых тестов на C# для REST API с использованием NUnit и библиотеки RestSharp. В этой статье я хочу поговорить об этом подробнее, показав, как сделать эти тесты управляемыми через данные.
Если вы не знаете, что имеется в виду под "управлением через данные": если я хочу запускать тесты, использующие одинаковую логику или поток в тестируемом приложении несколько раз с различными комбинациями входных значений и соответствующими ожидаемыми результатами, я называю это тестированием, управляемым через данными.
Это особенно полезно при тестировании REST API, так как в их основе лежит отправка и получение данных, а также открытие бизнес-логики другим уровням архитектуры приложения (например, графическому интерфейсу пользователя) или другим приложениям (пользователям API).
Автор: Баз Дейкстра (Bas Djikstra) Оригинал статьи Перевод: Ольга Алифанова
В этой короткой серии статей я хочу исследовать библиотеку запросов Python и то, как ее можно использовать для создания тестов REST API. Это первая статья, и она посвящена тому, как начать и написать первые тесты для выборочного REST API.
Автор: Энди Найт (Andy Knight) Оригинал статьи Перевод: Ольга Алифанова
Френд в Twitter недавно задал мне вопрос:
"Я работаю в команде Microsoft. У нас 40 разработчиков, использующих .NET (C#). У нас также несколько ручных тестировщиков и 5 автоматизаторов, которые разработали нашу тест-автоматизацию на Python. Однако руководство хочет полностью перенести все на C#.
Что лучше, а) научить 40 .NET-разработчиков Пайтону, чтобы пользоваться имеющимся решением, или б) научить тестировщиков .NET и портировать тесты на C#?"
Это очень сложный вопрос. Ответить на него сложнее, чем на вопрос о наилучшем языке тест-автоматизации, потому что тут уже имеются в наличии люди, позиции и решения. Честно говоря, я не могу дать исчерпывающего ответа без подробного контекста, но могу предложить пять советов.
Автор: Джош Грант (Josh Grant) Оригинал статьи Перевод: Ольга Алифанова
Продолжая исследовать Pytest и его замечательные возможности, хочу рассказать о плагине pytest, который по сути представляет из себя полноценный инструмент тест-автоматизации. Это pytest-bdd.
Pytest-bdd – это вариация более распространенных фреймворков вроде Cucumber или Behave, который сам по себе – по сути Python Cucumber. BDD – популярный подход, распространенный среди команд – как работающих с автоматизированным тестированием впервые, так и опытных, ищущих зрелую методологию для внедрения. Ключевая особенность BDD – это создание фича-файлов с применением специального неспециализированного синтаксиса, Gherkin. Это позволяет описывать фичи вначале в таком формате:
Автор: Энди Найт (Andy Knight) Оригинал статьи Перевод: Ольга Алифанова
Эта статья покажет вам наилучший способ обращения с Python-функциями "main".
Python похож на скриптовый язык: все строки в "модуле" Python (файле .py) выполняются всегда, когда этот файл запускается. Модулям не нужна функция main. Допустим, у нас есть модуль по имени stuff.py вот с каким кодом:
Автор: Энджи Джонс (Angie Jones) Оригинал статьи Перевод: Ольга Алифанова
Большинство людей тестируют API спустя рукава. В своем воркшопе "Азбука API" я прошу людей вручную протестировать API. Получая ответ, они, как правило, бросают на него взгляд и, возможно, тщательно проверяют некоторые ключевые поля. То же верно и для автотестов – обычно проверяются только ключевые поля.
Напомним, что XSS-атака – это тип инъекции кода: вредоносный код ошибочно интерпретируется как пользовательский ввод. Чтобы предотвратить этот тип инъекций, необходимо безопасно обращаться с вводом. Для веб-разработки существует два фундаментально разных подхода к безопасной обработке вводимой информации:
Шифрование, когда браузер интерпретирует пользовательский ввод только как данные, а не как код.
Валидация, фильтрующая пользовательский ввод – браузер интерпретирует его как код, игнорируя вредоносные команды.
Непрерывная интеграция – основная цель внедрения автоматизации тестирования на проекте, без нее смысл автоматизации меркнет. Однако единственно верного рецепта построения CI на проекте не существует, т.к. CI это практика и глобальный подход, который строится на конкретных технических решениях, коих сегодня великое множество. На прошлой конференции Вадим Зубович рассмотрел различные подходы к организации процесса непрерывной интеграции и показал множество «подводных камней», с которыми можно столкнуться при применении тех или иных инструментов и подходов
С 31 марта по 2 апреля ждем вас на четвертом выпуске конференции TestCon Moscow 2020. Уже составлена программа конференции.
А всем подписчикам портала мы предлагаем дополнительную скидку в 10% по промо коду SOFTWARE10.
