Сколько должен протестировать каждый модульный тест?
Я не совсем уверен, что понимаю ваш вопрос, но вы можете ссылаться на типы объектов, а не на примитивные типы. Этот вопрос тем более важен, поскольку примитивные типы, такие как int или double, не могут использоваться в качестве универсальных типов - отсюда и их классы обтекания, такие как Integer.
// This won't work
ArrayList<int> list = new ArrayList<int>();
// But this will
ArrayList<Integer> list = new ArrayList<Integer>();
Подводя итог, я бы сказал, что все объекты - и только объекты - могут быть reifiable. (И, следовательно, может использоваться в качестве экземпляра универсальных типов)
5 ответов
] Я бы рекомендовал разбить их как можно больше.
Для этого есть много причин, ИМХО, самые важные из них:
Когда один из ваших тестов не проходит, вы хотите иметь возможность как можно быстрее и безопаснее изолировать именно то, что пошло не так. Лучший способ добиться этого - каждый метод тестирования тестировать только одну вещь.
Каждый тест должен начинаться с чистого листа. Если вы создадите репозиторий один раз, а затем используете его в двух или более тестах, то у вас будет неявная зависимость от порядка этих тестов. Скажем, Test1 добавляет элемент в репозиторий, но забывает его удалить. Поведение Test2 теперь будет другим, что может привести к сбою вашего теста. Единственное исключение - неизменяемые данные.
Что касается ваших проблем со скоростью, я бы не стал беспокоиться об этом. Для такой чистой обработки кода .NET очень быстр, и вы никогда не заметите разницы. Как только вы перестанете ломать код и погрузитесь в такие вещи, как базы данных, вы почувствуете проблемы с производительностью, но как только вы это сделаете, вы столкнетесь со всеми проблемами «чистого листа», как описано выше, так что вы можете просто придется смириться с этим (или сделать как можно больше данных неизменными).
Чем точнее, тем лучше. Когда утверждение не выполняется в тестовом случае, тестовый пример больше не запускается. Последние части случая потенциально могут выявить другие ошибки.
Если между тестовыми примерами есть общий код, используйте функции настройки / удаления, чтобы позаботиться об этом, не слишком повторяя себя. Затраты времени часто незначительны. Если установка / разборка занимает слишком много времени, вероятно, вы выполняете не модульное тестирование, а автоматическое тестирование более высокого уровня. В идеале модульные тесты не должны иметь зависимостей файловой системы, сети, базы данных и т. Д.
Модульный тест должен точно проверять то, что описано в вашем техническом проекте с точки зрения функционального дизайна.
Я думаю, что "стандартный" ответ заключается в том, что он должен доходить до такой степени, что если есть ошибка в коде, он должен нарушить один тест, но не скрыть никаких других ошибок (не останавливать другие тесты не работают), когда этот не работает. Каждый тест проверяет одно, а два теста не проверяют одно и то же. Это идеал, не всегда достижимый. Назовите это руководством.
При этом, как говорится, это действительно искусство. Сначала я бы отложил проблемы с производительностью и больше сосредоточился на ремонтопригодности. У вас есть две с половиной-тройкой строк дублирования. Если дизайн изменится, его будет трудно поддерживать. Само по себе дублирование может быть решено с помощью метода настройки и поля в классе в этом случае, но главное, о чем нужно беспокоиться, - это ремонтопригодность.
Тесты должны быть достаточно маленькими, чтобы их можно было сопровождать, легко понимать,
Подход к оценке стоимости теста тесты - это определенно то, что вам нужно решить заранее и придерживаться его. Я не считаю, что все должны следовать одному и тому же подходу единообразно, поскольку разные команды и / или проекты имеют разные приоритеты в отношении кодирования, производительности, устранения неполадок, инфраструктуры тестирования и т. Д. Но постоянство всегда поможет:
- быстрее выявлять проблемы, поскольку вы заранее знаете, на какую глубину копать;
- тратите меньше времени на строительство ваши тесты;
- используют тот же набор тестовых вспомогательных классов, пока реализация тестов.
- запускать тесты достаточно быстро: не слишком быстро и не слишком медленно.
- организация тестов (комплектов, пакетов и т. д.)
Если вы решите, что производительность важнее, тогда внедрите более толстые тесты с большим количеством проверок / утверждения. Если вы решите, что устранение неполадок имеет первостепенное значение, изолируйте свои тесты по мере необходимости. Я не понимаю, почему толстые и хорошо структурированные тесты ошибочны. Такие тесты будут выполнять ту же работу, что и большее количество более тонких тестов, и не хуже.
Конечно, каждый тест по-прежнему должен фокусироваться на определенной функции / возможности, но это не совсем тема данной темы.