Соглашение об именах Суффикс JUnit или префикс Test

Ответ 1

Другой аргумент для суффикса - по крайней мере, на английском языке:

Класс обычно представляет собой существительное, это модель концепции. Экземпляр одного из ваших тестов будет "Тест MyClass". Напротив, метод будет моделировать какое-то действие, например "test [the] calculate [method]".

Из-за этого я всегда буду использовать "суффикс" для тестовых классов и префикс для тестовых методов:

the MyClass test          --> MyClassTest
test the calculate method --> testCalculate()

Ответ 2

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

Это также означает, что когда вы используете Open Type (Ctrl-T) в Eclipse, вы в конечном итоге видите как производственный код, так и его тест... что также является напоминанием, если вы не видите класс теста:)

Ответ 3

До JUnit 4 было обычным назвать тестовые классы SomethingTest, а затем запустить JUnit для всех классов, соответствующих *Test.java. В наши дни аннотация, управляемая JUnit 4, вам просто нужно аннотировать ваши методы тестирования с помощью @Test и делать с ней. Ваши тестовые классы, вероятно, будут находиться под другой структурой каталогов, чем ваш фактический источник (источник в src/ тестовых классах в test/), поэтому в наши дни префиксы/суффиксы в значительной степени несущественны.

Ответ 4

Не оскорблять кого-либо, но я считаю справедливым сказать, что "moreunit" гораздо менее известен, чем JUnit, который довольно вездесущ, и установил соглашение о суффиксах тестовых классов "Тест".

Хотя JUnit4 покончил с необходимостью соблюдать соглашения об именах классов и методов (например, postfix Test "и" prefix test "), я думаю, что оба они по-прежнему полезны для ясности.

Представьте себе ужас наличия src/test/java/.../MyClass.myMethod(), протестированного src/main/java/.../MyClass.myMethod()...

Иногда полезно отходить от соглашений JUnit3 - я нахожу, что методы настройки именования после того, что они делают ( "createTestFactory()" ) и аннотируют их "@Before", намного яснее, чем общий "setUp()",.

Это особенно полезно, когда необходимо выполнить несколько несвязанных действий по настройке - они могут быть в отдельных методах, каждый из которых помечен как @Before. Это очень хорошо передает независимость действий.

Ответ 5

Я предпочитаю использовать синтаксис TestClassName. При использовании другого синтаксиса мне трудно определить, что является тестом, и который является фактическим классом в редакторах, когда я открываю оба. Нужно искать Последние четыре буквы в названии утомительны, а также эти буквы не всегда отображаются.

Для меня другой синтаксис приводит к нескольким неправильным перестановкам между файлами каждый день, и это занимает много времени.

Ответ 6

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

Ответ 7

Я также использую MyClassTest_XXX, когда хочу разбить мой тест на несколько классов. Это полезно при тестировании большого класса, и я хочу, чтобы тесты были логически сгруппированы. (Невозможно управлять устаревшим кодом, чтобы этот сценарий появился.) Тогда у меня есть что-то вроде KitchenSinkTest_ForArray, KitchSinkTest_ForCollection и т.д.

Ответ 8

Я предлагаю MyClassTests.

Классы должны быть существительными, поэтому обычно используются MyClassTest и менее распространенные MyClassTests или MyClassTestCase или MyClassTestFixture. Технически экземпляр тестового класса JUnit представляет собой test fixture, но TestFixture для меня слишком многословно.

Я думаю, что MyClassTests наилучшим образом передает намерение, потому что в классе, как правило, несколько тестовых методов, каждый из которых представляет один тест (тестовый пример).

Ответ 9

Я предпочитаю суффикс: TestCase. это согласуется с: http://xunitpatterns.com/Testcase%20Class.html