Когда мы говорим о тестировании документации, то обычно подразумеваем тестирование требований, ТЗ. И это тестирование на полносту, однозначность и прочая. Смотрим, как новый функционал будет коррелировать со старым, не будет ли проблем. Заранее продумываем свои тесты, обсуждаем реализацию...
Однако помимо ТЗ есть еще куча другой документации, которую тоже стоит проверить. Как минимум вычитать, нет ли ошибок. Давайте посмотрим, какая бывает документация:
private static class Apple {
private String color;
public String getName() {return color;}
}
@Test
public void basic() {
Apple apple = mock(Apple.class);
when(apple.getName()).thenReturn("Red");
assertEquals("Red", apple.getName()); // true
}
Здравствуйте, меня зовут Дмитрий Карловский и (сколько себя помню) я борюсь со своим окружением. Ведь оно такое костное, дубовое, и никогда не понимает, что я от него хочу. Но в какой-то момент я понял, что хватит это терпеть и надо что-то менять. Поэтому теперь не окружение диктует мне, что я могу и не могу делать, а я диктую окружению каким ему быть.
Как вы уже поняли, далее речь пойдёт про инверсию контроля через "контекст окружения". Многим этот подход уже знаком по "переменным окружения" - они задаются при запуске программы и обычно наследуются для всех программ, которые та запускает. Мы же применим эту концепцию для организации нашего кода на TypeScript.
Итак, что мы хотим получить:
Джеймс Уиттакер известен прежде всего как автор книг и визионер в тестировании. Одна из самых известных его книг — «Как тестируют в Google». Помимо Google, он работал в других гигантах вроде Microsoft. В общем, этого человека интересно послушать, о чём именно он бы ни говорил.
Выступление Джеймса стало закрывающим докладом конференции, в нём он говорил не столько о тестировании, сколько о более общих вопросах. По мнению Джеймса, уже приходит эпоха ИИ, отличающаяся от эпохи традиционного программного обеспечения, и это скажется на тестировании. По-прежнему нужно будет проверять, что технологии работают как должны и радуют пользователей — но способы проверки изменятся.
Какие скиллы нам понадобятся, чтобы успешно работать в таком мире? Узнаем под катом — мы выложили видео доклада и подготовили его текстовый перевод. Далее повествование будет от лица спикера.
Пару недель назад команда Vulners опубликовала сравнение нескольких популярных WAF. Поймав себя на мысли - "а как оценивать качество его работы?", я решил разобрать подробнее тему security-тестов и критериев оценки Web Application Firewall. Статья пригодится, в первую очередь, тем, кому интересна тема веб-безопасности, ровно как и счастливым обладателям WAF.
Хабр, привет!
Специалисты «Рексофт» собрали актуальные инструменты, которые облегчат жизнь тестировщику и помогут быстрее справляться с привычными задачами.
Итак, поехали!
Меня зовут Александр Михайлов, я работаю в команде интеграционного тестирования компании ЮMoney.
Наша команда занимается приемочным тестированием. Оно включает в себя прогон и разбор автотестов на критичные бизнес-процессы в тестовой среде, приближенной по конфигурации к продакшену. Еще мы пишем фреймворк, заглушки, сервисы для тестирования — в целом, создаем экосистему для автоматизации тестирования и обучаем ручных тестировщиков автоматизации.
Надеюсь, что эта статья будет интересна как новичкам, так и тем, кто съел собаку в автоматизации тестирования. Мы рассмотрим базовый синтаксис Jenkins Pipeline, разберемся, как создать джобу на основе пайплайна, а также я расскажу про опыт внедрения неочевидной функциональности в CI — запуска и дожатия автотестов по условию.
Привет, меня зовут Фахридин Джамолидинов, я специалист департамента тестирования в «Ростелеком ИТ». Занимаюсь автоматизацией тестирования основного сайта компании rt.ru. Наш сайт – это не только витрина для информирования клиентов и продаж услуг и товаров для сегментов B2C, B2B и B2O, он ещё предназначен для обслуживания текущих клиентов: FAQ, чат, формы обратной связи, платежные формы и т.п. Он постоянно обновляется, и каждый раз после выпуска новой версии нужно проверять сотни страниц с богатым, динамичным UI на работоспособность в браузерах и адаптивность вёрстки.
Конечно же на этапе разработки применяется практика design review со стороны наших продуктовых дизайнеров, но нет-нет да проблемы всплывали: где-то элементы перекрываются, съезжаются, не сохраняется единый стиль.
Осознавая, что ручное регрессионное тестирование существующего UI превращается в кошмар и отнимает кучу времени, мы решили автоматизировать данный процесс. Сегодня мы покажем, как работает автотестирование по скриншотам – будем акцентировать внимание на функционал aShot, или как помочь автотестам «видеть» ошибки.
Сегодня я расскажу про плагины, которые помогают быстро заполнить поля тестируемой формы. Мой топ-3.
Мне понравился механизм аспектно-ориентированного программирования (АОП), который используется в Allure Framework для перехвата выполнения тестовых шагов, отмеченных аннотацией @Step. И я попробовал применить его в автотестировании, не подключая к тестам таких монстров, как Spring или Guice.
Под катом несколько полезных примеров использования аспектов.
Всем привет! Меня зовут Кирилл Поляков, я QA-инженер в компании Lamoda. Мы тестируем бекэнд большой e-commerce платформы. В этой статье я расскажу, как мы пришли к автотестам на языке разметки для тестирования микросервисов и делаем это с помощью инструмента собственной разработки – Gonkey, который позволяет использовать стандартизированный набор решений и легко писать тесты на Go.
Ранее мы уже писали о том, когда бывает нужна автоматизация тестирования и какие проверки при этом используют. Сегодня предлагаем обсудить использование инструментов на практике и оценить их производительность. С разрешения Giovanni Rago – автора серии полезных материалов о тестировании – мы перевели его статью «Puppeteer vs Selenium vs Playwright: сравнение скорости» (Puppeteer vs Selenium vs Playwright, a speed comparison). Статья будет интересна тем, кто задумывается о выборе подходящего инструмента автоматизации в своих проектах.
Майндмап, Майнд карта, интеллект-карта, ассоциативная карта, диаграмма связей и т.д. – устоявшегося русскоязычного термина пока нет.
Материал готовила для начинающих, но возможно и более опытные найдут полезные моменты.
На Хабре уже не раз писали о том, что у Selenium Grid есть проблемы, которые не решить простым способом (например: раз, два, три). В этой статье мы поделимся нашим опытом и расскажем, как нам в Wrike удалось построить стабильную инфраструктуру для Selenium-тестов.
TLDR: Мы написали своё open source решение и полностью заменили им Selenium Grid.
Любите ли вы тесты, как люблю их я: всеми фибрами души, со всей страстью и энтузиазмом, на которые только способен разработчик, жадный до полного покрытия кода?
В этой статье я расскажу о тестировании кода с помощью Puppeteer — сервиса, который позволяет проверять работу скриптов в их естественной среде обитания — в браузере. Это не полноценный туториал по Puppeteer, а скорее набор советов о том, как писать осмысленные и стабильно работающие тесты.
Это четвертая часть серии по тестированию React с мок компонентами. Во второй части мы рассмотрели базовую форму мок компонентов. В третьей части мы добавили возможность передачи дочерних компонентов. Теперь мы рассмотрим самую сложную часть головоломки: работу с несколькими экземплярами одного и того же мока.
Представьте себе, что для выполнения огромной массы интеграционных тестов больше не нужно держать ни физические, ни виртуальные сервера, постоянно лениво пожирающие Ваши деньги. Теперь можно платить только за выполненную работу. И выполненную, к слову, в разы быстрее.
Новый Serverless фреймворк Smith позволяет параллелить Ваши тесты на сотни серверов, выполняя их в разы быстрее. При этом выполнение будет происходить, по сути - Serverless. Вам больше не нужно держать парк гретых виртуалок - всё будет создано, использовано и погашено за Вас.
Готовые интеграции с системами управления тесткейсами упростят вам жизнь ещё сильнее.
И это всё - бесплатно. Давайте разберёмся - как это работает.