Каковы лучшие практики для написания модульных тестов с помощью фреймворков

Question

Каковы лучшие практики для написания модульных тестов с помощью фреймворков

1

Я новичок в насмешках, и я много изучил для лучших практик, но до сих пор я не мог найти ни одного удовлетворяющего ресурса, поэтому я подумал о том, чтобы включить SO.

Я пробовал несколько тестовых случаев и имел следующие сомнения:

Вы пишете отдельный unit тест для каждого метода (общедоступный частный и т.д.) И высмеиваете другие вызовы методов, вызываемые внутри этого метода, или вы проверяете только открытый метод?
Можно ли проверить вызов заглушенного метода в конце при тестировании метода, который ничего не возвращает, например, вставки БД?

Пожалуйста, добавьте другие методы, которые необходимо знать.

Atul 12 март 2014, в 17:50

Источник

Теги:

java

unit-testing

mockito

mocking

1 ответ

Ещё вопросы

jmkgreen · Accepted Answer · 2014-03-12T14-58-00.000Z

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

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

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

Извините, что вы расплывчаты, но приступаете к большой теме, и я хотел быть кратким.