2009-11-13 4 views
0

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

Например ...

@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 и модульного тестирования, но я просто не уверен, какие тесты нужно делать для простых методов. Не действительно «как» создавать тесты, а «что» тестировать.

ответ

0

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

Таким образом, этот метод получает параметр «вход» и передает его в entityManager.persist. Это работа. Поэтому мы используем какую-то насмешливую структуру, чтобы получить mock entityManager, и мы проверяем, действительно ли передан параметр addCategory для моего объекта entityManager. Вот и все. Мы протестировали все функции этого метода.

В более сложных сценариях это appraoch очень полезно, вы проверяете все условные в методе и забрать все виды «вне по одному» и неправильному использованию нулевых опорных ошибок и т.д.

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

Например:

Create a category object with an empty name 

Call Add Category 

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

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

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

и так далее.

+0

В более широком мире именования вещей это будет «интеграционное» тестирование? – Drew

+0

@ Дрю, да, это интеграционное тестирование. Я бы сказал, что общий способ мышления об интеграционном тестировании больше связан с интеграцией только что разработанных модулей, а не с кодом инфраструктуры. И здесь мы могли бы сосредоточиться конкретно на поведении Группы, внимательно глядя на ее угловые случаи. – djna

0

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

Смежные вопросы