LINUX.ORG.RU

Автоматическое тестирование сложных систем: хочется совета


0

0

Всем доброго времени суток.

Вопрос №1.

Как писать юниттесты к функциям и классам, которые получают что-то на вход и возвращают какой-то результат, вроде понятно: подаем input, сравниваем output с ожидаемым.

А как протестировать что-нибудь более хитрое? Например: сервер(неважно какой) результат своей деятельности записывает в базу данных, эти данные просматриваются через веб интерфейс (обновляются ajax-ом), к серверу коннектятся клиенты, которые вносят свои данные/изменения, + там же где-то еще и оповещения менеджерах о некоторых событиях.

Логика подсказывает, что это все нужно разбить на компоненты и тестировать их по отдельности. А как тестировать их взаимодействие (например, что джаваскрипты не сломали и они отправляют «правильные» запросы и запросы «правильно» отвечают)? Или сложные действия: реакция сервера на получение «плохих» данных от клиента итд?

Как это происходит в реальной жизни (в продакшне)?

Вопрос №2.

Не посоветуете ли какую-нибудь литературу по вопросу №1?

Спасибо за внимание.


> А как протестировать что-нибудь более хитрое?

Гугли Mock objects

BreadFan ★★
()

>эти данные просматриваются через веб интерфейс

Selenium (функциональное тестирование), JMeter (нагрузочное). Есть ещё всякая оффтопиковая проприетарщина.

Не посоветуете ли какую-нибудь литературу по вопросу №1?

Возможно, «Шаблоны корпоративных приложений» Мартина Фаулера. Хотя, наверно, там больше про архитектуру и дизайн, чем про само тестирование. К сожалению, ещё не добрался до этой книги.

А вообще, google integration testing может помочь.

Zloddey
()
Ответ на: комментарий от Zloddey

>Selenium

Watir/Watij/Watin же. и вообще есть мнение, что выбор инструментов для тестирования лучше оставить за тестировщиком.

Unclown
()
Ответ на: комментарий от Zloddey

Возможно, «Шаблоны корпоративных приложений» Мартина Фаулера. Хотя, наверно, там больше про архитектуру и дизайн, чем про само тестирование. К сожалению, ещё не добрался до этой книги.

Хм. Забавная книжечка. Щас полистаем, спасибо.

bibi
()

>Как это происходит в реальной жизни (в продакшне)?

За тестинг в продакшене обычно бьют больно :)

Есть два этапа тестирования - сначала тестируется низкий уровень на атомарных задачах, потом придумываются тесткейсы для сложных задач. Короче отдели мух от котлет.

lester_dev ★★★★★
()
Ответ на: комментарий от Unclown

Watir/Watij/Watin же

Всегда было интересно сколько у вас функциональных тестов на проект и как долго выполняется весь набор?

Пользователей seleniuma тоже хотелось бы услышать.

ТОРМОЗИТ ЖЕ!

По теме — htmlunit (в красивой groovy обертке).

baverman ★★★
()
Ответ на: комментарий от baverman

на одно и тоже приложение: selenium - здоровенная простыня на 2 с лишним часа. Watin - набор тестов, быстрее минут на 20 (скорее за счет использования в некоторых местах голого C# кода, ибо приложение .NETное ), ну и плюс нормально читается. Минус чистоте эксперимента - тесты для селениума и ватина писались разными людьми

и да, щупал htmlunit - не заметил впечатляющего прироста скорости. не говоря о том, что мерять качество тестирования скоростью исполнения тестов - дикость

Unclown
()
Ответ на: комментарий от Unclown

здоровенная простыня на 2 с лишним часа

Ух. Сочуствую.

не заметил впечатляющего прироста скорости

Если писать в стиле силениумовских тестов, то конечно, прирост мизерный. Но для частых операций, например регистрация пользователя, добавление какой-нибудь сущности (все сценарии которые покрыты своими тестами, но используются как часть других), можно напрямую дергать модель приложения, в обход медленной связки браузер->сервер. Тут то и можно хорошо сэкономить.

Опять таки распараллеливание тестов. Сейчас на тестовом сервере сюита гоняется в четыре потока (четыре клиента, четыре браузера), ничто мне не помешает, если упрусь в скорость билда, задеплоить еще один тестовый сервер и гонять тесты и на нем.

что мерять качество тестирования скоростью исполнения тестов - дикость

Я такого не говорил. У инженера две задачи: увеличить покрытие функционала и в то же время не допустить чрезмерного увеличения времени билда, иначе качество продукта пострадает. Пробуксовка CI, очень страшная штука. Замедленный фидбэк, приводит к увеличению времени между деплоем новых версий. Проваленные билды содержат, как правило больше зафейленных тестов, чем обычно, что удорожает диагностику и исправление. Невозможность гарантированно, в поставленный строк (до обеда ^_^) выкатить горячие фиксы, очень расстраивает менеджера. Скорость очень важна, естественно не в убыток покрытию.

baverman ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.