Размышление над этим вопросом в не зависящем от языка, не зависящем от фреймворка виде приводит к тому, что то, о чем вы просите, является несколько загадкой:
Инструмент тестирования не будет знать о времени выполнения какого-либо из модульных тестов, пока они не будут запущены; потому что это зависит не только от инструмента тестирования и самих тестов, но и от тестируемого приложения. Решением этой проблемы было бы сделать такие вещи, как установление лимита времени. Если вы сделаете это, тогда напрашивается вопрос, когда по истечении времени ожидания теста он будет пройден, провален или, возможно, попадет в какую-то другую (третью) категорию? ... загадка!
Таким образом, чтобы избежать этого, я предложил вам принять другую стратегию, при которой вы, как разработчик, решаете, какие подмножества всего набора тестов вы хотите запустить в различных ситуациях. Например:
- Набор дыма теста;
- т.е. тесты, которые вы хотели бы выполнять в первую очередь все время. Если что-то из этого не получится, вы не захотите выполнять какие-либо тесты. Поставьте в эту группу только действительно фундаментальные тесты.
- A минимальный набор тестов;
- Для вашего конкретного требования это будет набор тестов, содержащий все «быстрые» или «быстрые» тесты, и вы определяете, какие из них.
- A комплексный набор тестов;
- Тесты, которые не относятся ни к одной из других категорий. Для вашего конкретного требования это будут тесты, которые "медленные" или "длинные" .
При запуске ваших тестов вы можете выбрать, какие из этих поднаборов тестов запустить, возможно, сконфигурировав их в какой-либо форме скрипта.
Я использую этот подход с большим эффектом в автоматизированном тестировании (интегрирован в систему непрерывной интеграции). Я делаю это, имея скрипт, который, в зависимости от входных параметров, решает либо выполнить только тесты smoke плюс тесты минимальный ; или, альтернативно, тесты дым , тесты минимальный и комплексные тесты (т.е. все они).
НТН