Одна философия заключается в том, чтобы очень жестко относиться к модульному тестированию (прежде чем я объясню, что я имею в виду, позвольте мне сказать, что я сам редко следую этой философии). Вы проверяете, что этот модуль выполняет то, что должен делать, а не работает какое-либо зависимое программное обеспечение (такое как механизм персистентности).
Итак, ваш метод получает параметр input и передает его в entityManager.persist. Это работа. Таким образом, мы используем какой-то фальшивый фреймворк, чтобы получить фальшивый entityManager, и мы проверяем, что действительно параметр, переданный в вызов addCategory, получен моим entityManager. Вот и все. Мы проверили все обязанности метода.
В более сложных сценариях этот метод довольно полезен, вы тестируете все условные выражения в методе и обнаруживаете все виды "off-by-one" и неправильного использования нулевых ссылок и т. Д.
Что-то вроде этого примера, я не уверен, что мы собираемся найти интересные ошибки.
Поэтому я бы настраивал небольшие наборы тестов с использованием реального EntityManager, который раздвигает границы данных. И да, это не совсем «модульное» тестирование, но мне все равно - я хочу найти дефекты!
Например:
Create a category object with an empty name
Call Add Category
Что должно произойти? Я предполагаю, что мы намерены создать исключение? Итак, мы проверяем, что это действительно так.
Еще несколько тестов:
- Вставить, затем извлечь - проверить все поля
- Вставьте, затем вставьте дубликат, какую ошибку мы ожидаем
и т. Д.