Тестирование производительности по сравнению с поблочным тестированием
Я читаю Osherove "Искусство Поблочного тестирования", и хотя я еще не видел, что он говорит что-либо о тестировании производительности, две мысли все еще приходят в мою голову:
- Тесты производительности обычно не могут быть модульными тестами, потому что тесты производительности обычно должны работать в течение долгих промежутков времени.
- Тесты производительности обычно не могут быть модульными тестами, потому что проблемы производительности слишком часто проявляют в интеграции или системном уровне (или по крайней мере логика теста единого блока должна была воссоздать производительность среды интеграции, будет слишком включен, чтобы быть модульным тестом).
Особенно по первой вышеизложенной причине, я сомневаюсь, что имеет смысл для тестов производительности быть обработанным платформой поблочного тестирования (такой как NUnit).
Мой вопрос: мои результаты / склонности соответствуют мыслям о сообществе?
5 ответов
Я согласен с вашими выводами/выводами. Настоящие модульные тесты тестируют только часть системы, игнорируя, издеваясь или подделывая остальные по мере необходимости. Интеграционные тесты (или регрессионные тесты) проверяют большинство или все устройства, работающие вместе, и это является истинным показателем производительности.
Тесты производительности вполне могут состоять из модульных тестов.
Например, модульный тест может передать в метод несколько различных параметров и проверить, что метод возвращает ожидаемый результат. Тест производительности может выполнить этот модульный тест 1000 раз (или любое другое значение, которое имеет смысл для вас), при этом записывая все, от счетчиков ЦП и памяти, вплоть до того, сколько времени длился каждый тест.
Юнит-тесты не должны занимать времени на выполнение, потому что вы тестируете только очень специфический блок / систему. Например, если ваша тестируемая система представляет собой ClassA : IClassA, вы делаете имитацию / заглушку и тестируете только поведение ClassA, и не должны тестировать поведение, отличное от ClassA, например, если ClassA использует ClassB. Для этого вам следует внедрить макет классаВ вместо конкретного класса.
Что касается тестов производительности, то имеет смысл по-прежнему использовать такие средства тестирования, как NUnit / MBUnit / MavenThought, просто храните эти тесты в отдельной сборке и не вызывайте их как часть ваших модульных тестов.
Итак, если вы используете Rake для вызова тестов, некоторые из ваших задач могут выглядеть так:
Rake Test:All #Run all unit tests
Rake Test:Acceptance #Run all acceptance tests
Rake Test:Performance #Run all performance tests
Rake Test:Integration #Run all integration tests
Затем при непрерывной интеграции Test:All всегда вызывается после успешной сборки, в то время как Test:Performance вызывается в 12 часов ночи один раз в день.
В некоторых ситуациях вы можете использовать модульные тесты, чтобы убедиться, что операция завершается в течение определенного периода времени. Если вы хотите добавить в свою операцию больше функций, но не хотите жертвовать производительностью, вы можете использовать модульные тесты, чтобы подтвердить это. Конечно, такие модульные тесты зависят от машины, но вы можете добавить в уравнение некоторые дополнительные переменные или конфигурацию.
Все зависит от того, что вы называете тестированием производительности. При микрооптимизации конкретного кода я обычно использую что-то очень похожее на модульное тестирование (следует ли мне называть это модульным тестированием производительности ?). В основном это то, что я делаю в этом вопросе (хотя не заботясь об использовании фреймворка модульного тестирования). Но я также делаю такие вещи, чтобы оптимизировать свой производственный код C ++ в рамках модульного тестирования BOOST.
На самом деле существует множество видов тестирования производительности на разных уровнях и с разными целями (стресс-тест с большой нагрузкой, профилирование, микрооптимизация). Тестирование производительности, о котором вы говорите в своем вопросе, похоже, находится на уровне функционального тестирования. Уровень, для которого вы, вероятно, все равно не будете использовать фреймворк для модульного тестирования.