Эффективность блока тестирования в TDD
Допустим, нам нужна функция сортировки и мы хотим убедиться, что она реализована в O(nlogn), а не в O(n^2).
Существует ли систематический способ тестирования эффективности реализации этой функции с помощью разработки через тестирование?
Согласно Википедия, Детали реализации тестирования считается анти-шаблоном в разработке через тестирование, мешает ли это TDD любым попыткам проверить эффективность кода, удовлетворяющего требованию? Или есть систематический способ сделать это?
Ответы 2
На самом деле это не самое приятное место TDD — имейте в виду, что мотивация для TDD — не тестирование (хотя это приятный побочный эффект), а дизайн, то есть облегчение изменения кода.
Частью ритуала TDD является частый запуск тестов в течение цикла разработки; тесты, которые отвлекают от процесса разработки (например, из-за того, что их выполнение занимает много времени), недопустимы. Это не значит, что вы не можете пройти эти тесты; один из аргументов в пользу TDD заключается в том, что он гарантирует наличие тестируемого кода. Но обычно вы не ожидаете выполнения тестов, которые требуют значительного времени настенных часов во время ритуала красного/зеленого/перезапуска.
Кроме того, тесты, которые тесно связаны с реализацией, сильно тормозят, когда реализация нестабильна. Вы теряете доверие, когда тесты мешают изменению инкапсулированного дизайна в коде.
Иногда вы можете ввести требование наблюдаемости, чтобы снаружи системы вы могли подсчитывать, как часто вызывается критический раздел. И пока эта критическая секция используется системой, возможно, вы можете использовать подсчеты в качестве доказательства и оценить, масштабируется ли реализация так, как вы ожидаете.
В случае сортировки это может означать дизайн, в котором функция сравнения является настраиваемой зависимостью, а в тесте мы предоставляем реализацию, которая подсчитывает, как часто она вызывается.
Но это вводит некоторую связь - в этот момент вы измеряете, вызывается ли ваш метод, нет, дает ли испытуемый правильный ответ. В некоторых случаях это нормально. В других случаях это чрезмерное сцепление. Я не знаю какой-либо простой эвристики, которую вы могли бы использовать, чтобы различить два случая, не пытаясь провести эксперимент и не обжечься, когда произойдет чрезмерная связь.
Вместо TDD вы можете использовать test-after:
- Внедрить счетчик, который измеряет количество операций
- Запустите алгоритм для заданного ввода
- Подтвердите, что количество меньше порогового значения
Это предотвратит регрессию числа операций. (Имейте в виду, что это не гарантирует реальную производительность.)