Дело тестера боится: как в опытных руках могут заиграть Java и TestNgIT61
Вячеслав Марков, QA engineer в Weezlabs
Я расскажу о том, как в нашей фирме организовано тестирование бэкенда с помощью тестового фреймворка TestNG и Java. Расскажу о data-driven тестировании и о том, почему его удобно применять. Покажу и опишу разработанную нами структуру типового тестового проекта. Представлю применяемые нами способы сбора и документирования результатов, а так же их анализ в условиях CI.
Зачем тестировать? Тестирование в интерпретаторе и доктесты. Модуль unittest. Пакет py.test - на порядок лучше. Тестирование свойств и пакет hypothesis.
Дело тестера боится: как в опытных руках могут заиграть Java и TestNgIT61
Вячеслав Марков, QA engineer в Weezlabs
Я расскажу о том, как в нашей фирме организовано тестирование бэкенда с помощью тестового фреймворка TestNG и Java. Расскажу о data-driven тестировании и о том, почему его удобно применять. Покажу и опишу разработанную нами структуру типового тестового проекта. Представлю применяемые нами способы сбора и документирования результатов, а так же их анализ в условиях CI.
Зачем тестировать? Тестирование в интерпретаторе и доктесты. Модуль unittest. Пакет py.test - на порядок лучше. Тестирование свойств и пакет hypothesis.
Многие из нас слышали, что при создании тестовых систем необходимо понимать из каких слоев они должны состоять. Но начинающим специалистам очень сложно четко понять за чем эти слои нужны и какие функции они выполняют. В своем докладе я хотел бы внести ясность по данному вопросу и ответить на все все вопросы.
Трепещи, мир! Мы выпустили PVS-Studio 4.00 с бесплатным анализатором общего н...Tatyanazaxarova
Предлагаем вниманию программистов новый инструмент для поиска ошибок в исходном коде приложений на языке Си/Си++. В рамках анализатора PVS-Studio реализован новый набор правил общего назначения. Эта функциональность на данный момент является бесплатной.
"Опыт создания системы управления сборкой и тестированием" (полная)SPB SQA Group
Доклад посвящен вопросам создания и использования собственной системы управления процессами сборки и тестирования ПО. Описываются ключевые моменты построения таких систем, в частности: вопросы интерфейсов, быстродействия, качества и интеграции в общую инфраструктуру. Затрагиваются концепции встраивания качества в код, сбора и использования метрик ПО, неотделимости сборки от тестирования, автоматизированного ведения базы знаний об ошибках и другие.
Модели в профессиональной инженерии и тестировании программ. Александр Петрен...yaevents
Александр Петренко, ИСП РАН
Профессор, доктор физико-математических наук, заведующий отделом технологий программирования Института системного программирования (ИСП РАН), профессор ВМК МГУ. Основные работы в областях: формализация требований, генерация тестов на основе формализованных требований и формальных моделей (model based testing – MBT). Приложения: тестирование операционных систем и распределенных систем, тестирование компиляторов, верификация дизайна микропроцессоров, формализация стандартов на API операционных систем и телекоммуникационных протоколов. Сопредседатель оргкомитетов International MBT workshop (http://www.mbrworkshop.org/), Spring Young Researcher Colloquium on Software Engineering – SYRCoSE (http://syrocose.ispras.ru), городского семинара по технологиям разработки и анализа программ ТРАП/SDAT (http://sdat.ispras.ru/).
Тема доклада
Модели в профессиональной инженерии и тестировании программ.
Тезисы
Model Based Software Engineering (MBSE) является расширением подхода к разработке программ на основе моделей. В MBSE в отличие, например, от MDA (Model Driver Architecture) существенное внимание уделяется не только задачам собственно проектирования и разработки кода, но и задачам других фаз жизненного цикла – анализу требований, верификации и валидации, управлению требованиями на всех фазах жизненного цикла. Model Based Testing (MBT) хронологически возник гораздо раньше, чем MBSE и MDA, однако его место в разработке программ в полной мере раскрылось вместе с развитием MBSE. По этой причине MBT и MBSE следует рассматривать в тесной связке. В докладе будут рассмотрены концепции MBSE-MDA-MBT, основные источники и виды моделей, которые используются в этих подходах, методы генерации тестов на основе моделей, известные инструменты для
Готов ли JUnit 5 к использованию в production? Как на него перевести большой проект и сделать тесты лаконичнее? В своем докладе я выскажу свои мысли о концепциях, заложенных в JUnit 5 и поделюсь нашим успешным опытом миграции на новую платформу
Практические основы тестирования на php Unit-test: понятия, тонкости, пути решения, вопросы для проработки.
PHPUnittest fast start
Разработано http://webgloss.ru
Многие из нас слышали, что при создании тестовых систем необходимо понимать из каких слоев они должны состоять. Но начинающим специалистам очень сложно четко понять за чем эти слои нужны и какие функции они выполняют. В своем докладе я хотел бы внести ясность по данному вопросу и ответить на все все вопросы.
Трепещи, мир! Мы выпустили PVS-Studio 4.00 с бесплатным анализатором общего н...Tatyanazaxarova
Предлагаем вниманию программистов новый инструмент для поиска ошибок в исходном коде приложений на языке Си/Си++. В рамках анализатора PVS-Studio реализован новый набор правил общего назначения. Эта функциональность на данный момент является бесплатной.
"Опыт создания системы управления сборкой и тестированием" (полная)SPB SQA Group
Доклад посвящен вопросам создания и использования собственной системы управления процессами сборки и тестирования ПО. Описываются ключевые моменты построения таких систем, в частности: вопросы интерфейсов, быстродействия, качества и интеграции в общую инфраструктуру. Затрагиваются концепции встраивания качества в код, сбора и использования метрик ПО, неотделимости сборки от тестирования, автоматизированного ведения базы знаний об ошибках и другие.
Модели в профессиональной инженерии и тестировании программ. Александр Петрен...yaevents
Александр Петренко, ИСП РАН
Профессор, доктор физико-математических наук, заведующий отделом технологий программирования Института системного программирования (ИСП РАН), профессор ВМК МГУ. Основные работы в областях: формализация требований, генерация тестов на основе формализованных требований и формальных моделей (model based testing – MBT). Приложения: тестирование операционных систем и распределенных систем, тестирование компиляторов, верификация дизайна микропроцессоров, формализация стандартов на API операционных систем и телекоммуникационных протоколов. Сопредседатель оргкомитетов International MBT workshop (http://www.mbrworkshop.org/), Spring Young Researcher Colloquium on Software Engineering – SYRCoSE (http://syrocose.ispras.ru), городского семинара по технологиям разработки и анализа программ ТРАП/SDAT (http://sdat.ispras.ru/).
Тема доклада
Модели в профессиональной инженерии и тестировании программ.
Тезисы
Model Based Software Engineering (MBSE) является расширением подхода к разработке программ на основе моделей. В MBSE в отличие, например, от MDA (Model Driver Architecture) существенное внимание уделяется не только задачам собственно проектирования и разработки кода, но и задачам других фаз жизненного цикла – анализу требований, верификации и валидации, управлению требованиями на всех фазах жизненного цикла. Model Based Testing (MBT) хронологически возник гораздо раньше, чем MBSE и MDA, однако его место в разработке программ в полной мере раскрылось вместе с развитием MBSE. По этой причине MBT и MBSE следует рассматривать в тесной связке. В докладе будут рассмотрены концепции MBSE-MDA-MBT, основные источники и виды моделей, которые используются в этих подходах, методы генерации тестов на основе моделей, известные инструменты для
Готов ли JUnit 5 к использованию в production? Как на него перевести большой проект и сделать тесты лаконичнее? В своем докладе я выскажу свои мысли о концепциях, заложенных в JUnit 5 и поделюсь нашим успешным опытом миграции на новую платформу
Практические основы тестирования на php Unit-test: понятия, тонкости, пути решения, вопросы для проработки.
PHPUnittest fast start
Разработано http://webgloss.ru
3. Неформальный процесс тестирования пакета
1. Добавляете в пакет новую функцию
2. Загружаете весь функционал пакета с помощью devtools::load_all()
3. В ручном режиме тестируете новую функцию в консоли
4. В случае ошибки вносите изменения и повторяете итерацию
4. ВЕРНУВШИСЬ К КОДУ ПАКЕТА
СПУСТЯ НЕСКОЛЬКО
МЕСЯЦЕВ ДЛЯ ДОБАВЛЕНИЯ
НОВОГО ФУНКЦИОНАЛА ВЫ
ВРЯД ЛИ ВСПОМНИТЕ ВСЕ
ПРЕДЫДУЩИЕ ТЕСТЫ
6. Рабочий процесс тестирования
• С помощью функции usethis::use_testthat(3) настройте ваш пакет для тестирования
• При запуске будет создан каталог tests/testthat/
• В поле Suggests файла DESCRIPTION будет добавлен пакет testthat
• Создастся файл tests/testthat.R, который отвечает за запуск ваших тестов
• Создание функций и тестов к ним осуществляется двумя функциями
• usethis::use_r() – создаёт файл будущей функции в каталоге R/
• usethis::use_test() – создаёт файл test-function_name.R с тестами для функции в каталоге
tests/testthat/
• Запуск тестов осуществляется функцией devtools::test()
7. Организация тестов
• Файл содержит несколько связанных тестов.
• Тест объединяет несколько ожиданий для проверки выходных данных простой функции,
диапазона возможностей для одного параметра более сложной функции или тесно
связанныx нескольких функций. Тест создается с помощью test_that(desc, code), где:
• desc - краткое описание теста. Отчет о сбое теста включает это описание, поэтому вам нужно краткое
изложение цели теста, например, конкретного поведения.
• code – код теста, который зачастую состоит из ожиданий
• Ожидание — это атом тестирования. Он описывает ожидаемый результат вычисления:
имеет ли он правильное значение и правильный класс? Выдает ли он ошибку, когда
должен? Функции ожиданий имеют префикс expect_*()
8. Ожидания
• expect_equal(), expect_identical() - Возвращает ли код ожидаемое значение?
• expect_type(), expect_s3_class(), expect_s4_class() - Возвращает ли код объект,
унаследованный от ожидаемого базового типа, класса S3 или класса S4?
• expect_error(), expect_warning(), expect_message(), expect_condition() - Выдает ли код
ошибку, предупреждение, сообщение или другое условие?
• expect_length() - Возвращает ли код вектор указанной длины?
• expect_lt(), expect_lte(), expect_gt(), expect_gte() - Возвращает ли код число больше/меньше
ожидаемого значения?
• expect_named() - Возвращает ли код вектор с (заданными) именами?
• …
9. Snapshot тесты
• Snapshot тесты запоминают вывод, который был в консоли при первом его выполнении, и в
будущем сравнивают текущий вывод полученный при запуске тестов, с зафиксированным
при первом запуске значениям.
• Snapshot тесты работают только в пакетном (не интерактивном) режиме работы, т.е. их
можно запустить командой devtools::test().
• При первом запуске создаётся папка tests/testthat/_snaps/ в которую и будут собираться
снимки вывода результата работы функции в виде .md файлов.
• При каждом следующем запуске теста, вывод работы функции будет сравниваться с
созданным ранее эталоном.
10. Управление Snapshot тестами
• Команда testthat::snapshot_review() запускает Shiny приложение для локального просмотра
отличия в выводе функции, по сравнению с эталоном.
• Команда testthat::snapshot_accept() позволяет обновить эталонный снимок теста.