Модульные тесты на JPA / персистентность в целом - PullRequest
0 голосов
/ 14 ноября 2009

Как / вы будете тестировать сверхпростые методы, построенные на постоянном движке. Я собираюсь использовать JPA, но у любого механизма персистентности, я уверен, есть свои эквиваленты.

Например ...

@Entity
public class Category {

   @Id @GeneratedValue
   private long id;

   @NotNull @NotEmpty
   private String name;

   @NotNull
   @ManyToOne
   private User user;

   //...Getters/Setters...
}

@Stateless
public void CategoryServiceImpl implements CategoryService {

   @PersistenceContext EntityManager entityManager;
   public void addCategory(Category input) {
      entityManager.persist(input);
   }
}

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

Ответы [ 2 ]

0 голосов
/ 08 мая 2014

Вместо интеграционного тестирования с существующей базой данных вы можете выполнять достойные модульные тесты, выполняя свои тесты для встроенной в память базы данных, такой как h2, которая была настроена для создания всех своих таблиц на основе аннотаций соединения. Это хорошо работает для нас с базой данных около двухсот таблиц.

0 голосов
/ 14 ноября 2009

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

Итак, ваш метод получает параметр input и передает его в entityManager.persist. Это работа. Таким образом, мы используем какой-то фальшивый фреймворк, чтобы получить фальшивый entityManager, и мы проверяем, что действительно параметр, переданный в вызов addCategory, получен моим entityManager. Вот и все. Мы проверили все обязанности метода.

В более сложных сценариях этот метод довольно полезен, вы тестируете все условные выражения в методе и обнаруживаете все виды "off-by-one" и неправильного использования нулевых ссылок и т. Д.

Что-то вроде этого примера, я не уверен, что мы собираемся найти интересные ошибки. Поэтому я бы настраивал небольшие наборы тестов с использованием реального EntityManager, который раздвигает границы данных. И да, это не совсем «модульное» тестирование, но мне все равно - я хочу найти дефекты!

Например:

Create a category object with an empty name

Call Add Category

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

Еще несколько тестов:

  1. Вставить, затем извлечь - проверить все поля
  2. Вставьте, затем вставьте дубликат, какую ошибку мы ожидаем

и т. Д.

...