Один тест-класс за метод?

Question

С сегодняшнего дня я использовал шаблон для создания одного тестового класса для каждого класса. Например, класс «Foo» с методами «DoSomething» и «DoNothing» имел один тестовый класс под названием «FooTests».

Теперь я слышал о создании одного тестового класса для каждого метода. В предыдущем примере это означало бы, что вместо класса «FooTests» я создаю два новых класса «DoSomethingTests» и «DoNothingTests».

Является ли это обычно используемым шаблоном, и я должен переключиться на это, или это, кроме того, анти-шаблон?

Спасибо вам за помощь.

Answer 1

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

Answer 2

Я не вижу причины вводить классы тестов для каждого метода. Честно говоря, я никогда не видел такой стратегии тестирования.

Конечно, вы можете разбить свои тестовые классы, если у вас есть причина для этого. Вы можете извлечь общие части тестов в разделенных вспомогательных классах. В некоторых случаях наследование между классами тестов также является разумным.

Нет никакой разницы между тестовым кодом и производственным кодом. Ваш тестовый код должен быть четким, читаемым и обслуживаемым. Я думаю, что идеология «Один тест-класс за метод» может испортить ее.

Answer 3

Я думаю, что это все о том, когда применять такую ​​вещь. Я бы сказал, что в целом вы должны не создавать тестовый класс для каждого метода тестирования. Я бы рекомендовал методы группировки с одинаковой функциональностью (например, методы в одном классе) в одном тестовом классе. Однако исключение может быть чрезвычайно сложным методом, требующим десятков тестов для проверки его поведения. В этом случае может оказаться полезным один класс тестов. Вы должны быть осторожны при создании исключений, так как это делает способ структурирования кода менее очевидным.

Answer 4

Главное преимущество создания одного класса испытаний на производственный класс состоит в том, что он прост и понятен. Если у вас есть Foo, вы точно знаете, что все модульные тесты для Foo всегда можно найти в FooTest (или независимо от того, что называет ваше соглашение об именах). Вы следуете соглашению об именах для имен классов модульных тестов, не так ли?)

Для удобства чтения я рекомендую вашей команде определить соглашение об именах, которое помогает идентифицировать тесты. Например, я могу назвать один из тестов FooTest::DoSomething_ensureNullPointerThrowsException(). Таким образом, читатель знает не только тест Foo::DoSomething(), но также знает, что он тестирует исключение нулевого указателя.

В целом, если что-то кажется «неправильным» или «трудно сделать»; если вы думаете, что было бы проще сделать что-то по-другому, потому что ваш проект просто не мешает тому, как это делают все остальные; это часто связано с нарушениями одного или нескольких принципов проектирования ОО. Взгляните глубоко на первопричину: почему я борюсь с проблемой X? Почему кто-то хочет получить один тестовый класс для каждого метода производства? Есть ли сто тестов для каждого метода, и разработчик считает, что изменение будет лучше сгруппировать их? Вероятная причина в том, что его методы несут слишком большую ответственность или слишком сложны. Если бы его методы были более простыми, он мог бы найти, пожалуй, всего пять или десять тестов для каждого метода.