На SQA Days 12 мы обсуждали "будущее тестирования". Каким оно будет через десять лет? Умные роботы, которые сами ищут баги, а лучше и сразу их исправляют?
И вот не так давно мы начали работу над новым проектом, и для документирования API на этом проекте разработчики воспользовались сервисом apiary.
Обычно мы пишем тесты для API на Python, запуская nosetests и получаем отчёт в Jenkins CI. Если проект активно развивается, то API постоянно расширяется и изменяется, тесты постоянно необходимо поддерживать в актуальном состоянии.
То есть мы каждый день начинаем с проверки последних запусков автоматизированных тестов и общения с разработчиком, который подсказывает нам, как мы можем протестировать новые функции, которые он добавил вчера.
Казалось бы, как можно иначе?
- разработчик пишет код
- разработчик пишет unit тесты (если пишет, да)
- разработчик обновляет документацию (не известно когда и мы, конечно, не застрахованы от ошибок и опечаток в документации)
- автоматизаторы обновляют интеграционные тесты.
Сервис apiary позволяет изменить этот подход, исключив явно лишние шаги из этого списка.
У вас есть документация, описывающая все запросы к вашему API интерфейсу, и вы можете запускать автоматизированные тесты, которые будут посылать запросы, основываясь на описанных в документации примерах.
И теперь всё выглядит вот так:
- разработчик пишет код
- разработчик обновляет документацию
- автоматизированные тесты на основе документации проводят интеграционное тестирование (проверяем работоспособность нового кода и актуальность документации)
Конечно, такими тестами проверим не всё, и мы дополнительно всё равно пишем тесты с более сложными сценариями, чем тем, что описаны в документации. Но это уже "отлично" подходит для быстрой проверки нового кода, ведь разработчик может проверить новый код сразу же, не дожидаясь написания автоматизированных тестов, и это интеграционные тесты, т.е. мы запускаем реальное приложение и проверяем его работоспособность. И документация всегда в актуальном состоянии, а значит, мы можем приступать к написанию более сложных сценариев основываясь на этой документации.
Встречайте инструмент Судья Dredd
ссылка на репозиторий
статья в блоге с описанием инструмента
Это ещё не те роботы, которые сами будут искать баги, но это отличный шаг вперёд, при этом у меня появляются сомнения в том, что именно роботы будут искать баги. Гораздо быстрее появятся системы и практики разработки, которые будут автоматически проводить проверку функционала на основе кода, документации и требований.
А мы будем заниматься чем-то другим, например, проработкой требований, историй использования, обновлением документации и поддержкой пользователей.
И вот не так давно мы начали работу над новым проектом, и для документирования API на этом проекте разработчики воспользовались сервисом apiary.
Обычно мы пишем тесты для API на Python, запуская nosetests и получаем отчёт в Jenkins CI. Если проект активно развивается, то API постоянно расширяется и изменяется, тесты постоянно необходимо поддерживать в актуальном состоянии.
То есть мы каждый день начинаем с проверки последних запусков автоматизированных тестов и общения с разработчиком, который подсказывает нам, как мы можем протестировать новые функции, которые он добавил вчера.
Казалось бы, как можно иначе?
- разработчик пишет код
- разработчик пишет unit тесты (если пишет, да)
- разработчик обновляет документацию (не известно когда и мы, конечно, не застрахованы от ошибок и опечаток в документации)
- автоматизаторы обновляют интеграционные тесты.
Сервис apiary позволяет изменить этот подход, исключив явно лишние шаги из этого списка.
У вас есть документация, описывающая все запросы к вашему API интерфейсу, и вы можете запускать автоматизированные тесты, которые будут посылать запросы, основываясь на описанных в документации примерах.
И теперь всё выглядит вот так:
- разработчик пишет код
- разработчик обновляет документацию
- автоматизированные тесты на основе документации проводят интеграционное тестирование (проверяем работоспособность нового кода и актуальность документации)
Конечно, такими тестами проверим не всё, и мы дополнительно всё равно пишем тесты с более сложными сценариями, чем тем, что описаны в документации. Но это уже "отлично" подходит для быстрой проверки нового кода, ведь разработчик может проверить новый код сразу же, не дожидаясь написания автоматизированных тестов, и это интеграционные тесты, т.е. мы запускаем реальное приложение и проверяем его работоспособность. И документация всегда в актуальном состоянии, а значит, мы можем приступать к написанию более сложных сценариев основываясь на этой документации.
Встречайте инструмент Судья Dredd
ссылка на репозиторий
статья в блоге с описанием инструмента
Это ещё не те роботы, которые сами будут искать баги, но это отличный шаг вперёд, при этом у меня появляются сомнения в том, что именно роботы будут искать баги. Гораздо быстрее появятся системы и практики разработки, которые будут автоматически проводить проверку функционала на основе кода, документации и требований.
А мы будем заниматься чем-то другим, например, проработкой требований, историй использования, обновлением документации и поддержкой пользователей.
Комментариев нет:
Отправить комментарий
Я признателен Вам за то, что делитесь своим мнением