Выбор имен для интеграционных тестов

С юнит-тестами домен довольно маленький, так что это легко. Я использовал methodName_conditions_result()схему Ошерова и нашел ее очень ясной.

Но с интеграционными тестами я чувствую, что это сделало бы очень длинное имя, и что я должен поставить вместо methodName? Как назвать интеграционные тестовые классы?

Примеры реальных имен интеграционных тестов приветствуются. Я надеюсь, что ответы также помогут мне лучше понять эти тесты.

Я использую немного другой подход в модульных и интеграционных тестах. Я стараюсь называть их по возможности как можно больше. Затем, когда все тесты пройдены, вы можете увидеть список всех функций, которые работают и не работают.

• canRegisterUser
• canHandleInvalidInput
• canRelayDocumentBetweenServers
• canCreateSchema
• canLoginUsingWebService
• canLoginUsingBasicAuth
• canDeleteDocument
• canAddDocument

Не всегда прагматично называть тесты таким образом, но это может быть очень полезно, особенно после прочтения сотен модульных и интеграционных тестов. Общее имя класса, содержащее эти методы, также должно указывать на тестируемые функции. Это поможет с организацией.

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

Это было действительно написано, чтобы помочь с модульными тестами, но, возможно, вы обнаружите, что те же правила применяются (более или менее) к интеграционным тестам:

Проверьте семь шагов !

Я предпочитаю, чтобы вы ни называли это, на самом деле это имя набора тестов (имя прибора на нашей карте), проверяемый эффект и сообщение с подтверждением, которые должны выделяться и объяснять причину ошибки. Если вы найдете, что это проще всего с именами Ашерова, то я искренне одобряю это. Но, возможно, хитрость в том, что вы заполняете часть «method» тем, что имеет смысл для условия, результата и исключения.

Я рад видеть пакет с именем «MakingADeposit» с тестом «AccountDoesntExist» и ошибкой «Неожиданное исключение NonesuchAccount - ни одного не получено».

В качестве альтернативы, если вы не возражаете против разделения имени набора тестов на «::», я в порядке с «AccountHandling :: MakingADeposit_AccountDoesntExist_ThrowsAnException»

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

Интеграционные тесты должны следовать некоторым правилам, аналогичным модульным, в том, что каждый тест должен тестировать один аспект требования, но тестирует систему в целом. Класс должен назвать всю проверяемую вещь, например, «TpcInputValidation», а наименование метода должно четко отражать то, что пытается сделать тест, не будучи чрезмерно многословным, например «shouldRaiseValidationErrorWithBadDates ()».

Методы должны проверять одну концепцию функции, а большое количество утверждений может указывать на обратное. (См. «Чистый код: Справочник по мастерству гибкого программного обеспечения», стр. 132, Роберт Мартин).

Итак, проблема в том, что собственное имя функциональности слишком длинное для имени метода? Я знаю, что неудобно начинать писать тестовые методы с именами, такими как registerAndValidateUnderageUniversityDriverWithCoverageSetA_test()и могут когда-либо нарушать правила компилятора для длинных имен методов (PL / SQL допускает только до 30 символов - я не знаю, накладывают ли Java и C # такие ограничения на короткие имена, но даже если они этого не делают, это довольно громоздко проходит определенную точку, и действительно очень длинные имена методов могут быть полезны только для сгенерированного кода, который читается / управляется другим сгенерированным кодом). Вы можете попытаться сократить это до, regValUnderageUnivDrvrWCovrgA_test()но это также действительно ужасно читать. Один вариант, который я использовал, который мне не нравился, но был лучшим выбором в то время:underageUnivDrvr_test_01()и затем была электронная таблица, отображающая имена методов в гораздо более длинное описание тестируемой функциональности. Ужасно, но это сработало. Вы также можете задокументировать описание теста в документации по функции в исходном файле, что может быть полезно, поскольку вы можете генерировать документацию по тестам непосредственно из кода, а не отображать данные между таблицей и кодом.