С 29 июня по 3 июля 2020 года в онлайн-формате прошла Java-конференция JPoint 2020. Информация о докладах, спикерах, особенностях проведения, впечатления от конференции — всё это можно прочитать далее.
Рубрика «pact»
JPoint 2020: новый формат, новые возможности
2020-07-04 в 17:01, admin, рубрики: graalvm, java, jmh, jpoint, jug.ru, kotlin, oracle, pact, protobuf, quarkus, scala, spring, valhalla, конференции
Consumer Driven Contracts или Gitlab CI глазами QA test automation
2019-05-09 в 13:16, admin, рубрики: Consumer Driven Contracts, gitlab ci, pact, python, микросервисы, Тестирование веб-сервисов, Тестирование мобильных приложенийЦели данной публикации:
- Краткое введение в Consumer Driven Contracts (CDC)
- Настройка CI pipeline на основе CDC
Consumer Driven Contracts
В этой части мы пройдемся по основным моментам CDC. Данная статья не является исчерпывающей на тему контрактного тестирования. Существует достаточное количество материалов на эту тему на том же Хабре.
Для продолжения нам необходимо познакомиться с основными положениями CDC:
- Контактное тестирование находится на уровне Service/Integration Tests над Unit Tests согласно пирамиде автотестирования (Mike Cohn)
- Контрактное тестирование может применяться, когда есть 2 (или более) сервиса, которые взаимодействуют друг с другом
- Сonsumer driven подход означает, что первым шагом в реализации является написание теста на стороне потребителя. Результатом теста является пакт (контракт) в формате json, который описывает взаимодействие между потребителем (например, веб-интерфейс / мобильный интерфейс: сервис, который хочет получить некоторые данные) и поставщиком (например, серверный API: сервис, который предоставляет данные)
- Следующим шагом является проверка договора с провайдером. Это полностью осуществлено фреймворком Pact.Читать полностью »
Пирамида тестов на практике
2018-05-20 в 11:38, admin, рубрики: CDC-тесты, devops, Galen, headless-браузер, json, junit, mockito, pact, REST-assured, selenium, solid, spring, tdd, wiremock, YAGNI, интеграционные тесты, контрактные тесты, Микроформаты, модульные тесты, пирамида тестов, Тестирование IT-систем, Тестирование веб-сервисов, управление разработкой, юнит-тесты
Об авторе: Хэм Фокке — разработчик и консультант ThoughtWorks в Германии. Устав от деплоя в три ночи, он добавил в свой инструментарий средства непрерывной доставки и тщательной автоматизации. Сейчас налаживает такие системы другим командам для обеспечения надёжной и эффективной поставки программного обеспечения. Так он экономит компаниям время, которое эти надоедливые людишки тратили на свои выходки.
«Пирамида тестов» — метафора, которая означает группировку тестов программного обеспечения по разным уровням детализации. Она также даёт представление, сколько тестов должно быть в каждой из этих групп. Несмотря на то, что концепция тестовой пирамиды существует довольно давно, многие команды разработчиков по-прежнему пытаются неправильно реализовать её на практике должным образом. В этой статье рассматривается первоначальная концепция тестовой пирамиды и показано, как её воплотить в жизнь. Она показывает, какие виды тестов следует искать на разных уровнях пирамиды, и даёт практические примеры, как их можно реализовать.
Содержание
- Важность автоматизации (тестов)
- Пирамида тестов
- Какие инструменты и библиотеки мы рассмотрим
- Пример приложения
- Юнит-тесты
- Интеграционные тесты
- Контрактные тесты
- Тесты UI
- Сквозные тесты
- Приёмочные тесты — ваши фичи правильно работают?
- Исследовательское тестирование
- Путаница с терминологией в тестировании
- Внедрение тестов в конвейер развёртывания
- Избегайте дублирования тестов
- Пишите чистый код для тестов
- Заключение
Примечания
Стартап, который платил деньги своим пользователям за тренировки, обанкротился
2017-09-25 в 14:16, admin, рубрики: pact, банкротство, зож, Регулирование IT-сектора, стартап, США, финансы, фитнес
Несколько лет назад СМИ начали активно распространять информацию о необычном стартапе. В общем-то, многие стартапы можно назвать необычными, но Pact предлагал уникальную модель работы. А именно — компания платила своим пользователям за тренировки. Деньги в этом случае служили мотивацией, и авторы проекта утверждали, что лучшей мотивации и быть не может (в принципе, они не так уж и неправы, правда?).
Для того, чтобы начать получать деньги, пользователю нужно было поставить определенные фитнес-цели, а дальше их придерживаться. Если все шло гладко, то компания выплачивала дисциплинированному пользователю деньги. Вознаграждение предлагалось очень небольшое, но и оно служили неплохим стимулом продолжать занятия. Хотя нет, скорее, более сильным стимулом были штрафы за несоблюдение условий.
Читать полностью »