Как проверить, вставлена ​​ли сущность JPA? - PullRequest
Новая
       28

Как проверить, вставлена ​​ли сущность JPA?

1 голос
/ 24 декабря 2011

  1. Вопрос в том, как проверить, работает ли постоянная сущность или нет. Я думаю, что имеет смысл проверить, правильно ли сопоставление сущностей JPA и все ли работает должным образом, особенно для сопоставления сложных сущностей с @ OneToMany / @ ElementCollection / @ ManyToMany / @ OneToOne с cascade атрибутами (CascadeType.ALL, например). И убедитесь, что все ограничения FK / PK / Unique выполнены.

  2. Это общий вопрос. Конкретная часть о Spring Testing Framework. Вы можете увидеть в коде ниже, где слой DAO тестирует, но поскольку метод тестирования помечен как @ Transactional , изменения должны быть откатаны, здесь должен вместо must , потому что, насколько я могу быть уверен, изменения вообще были сохранены в базе данных, вероятно, все хранится в памяти, потому что транзакция была помечена для отката, поэтому никакие данные на самом деле не отправляются база данных?

  3. Более важно, что этот тест не пройден, потому что account.getId () возвращает 0 (генерация идентификатора выполняется с использованием @SequenceGenerator), но кажется, что это значение никогда не присваивается в поле идентификатора учетной записи. Этот тест проходит только тогда, когда метод аннотирован @Rollback (false), поэтому, конечно, отката не происходит.

  4. Прав ли я, что в этом случае, когда используется @Transactional для тестирования, все находится в памяти (по крайней мере, до тех пор, пока не вызывается flush ()), поэтому проверить работоспособность базы данных невозможно .

  5. И в соответствии с приведенными выше соображениями, каков подходящий способ проверить вставку сущности и убедиться, что вставка выполнена, а затем откатить все до исходного состояния, чтобы запустить другие тесты? (очищать базу данных внутри @ Перед каждым выполнением теста?)

  6. Я не хочу использовать DBUnit, с помощью Spring нет никакого смысла использовать DBUnit. 

    @ContextConfiguration(
locations = {...})
@RunWith(SpringJUnit4ClassRunner.class)
public abstract class JpaRepositoryTest {
}

public class JpaAccountRepositoryTest extends JpaRepositoryTest {
    @Inject
    private AccountRepository accountRepository;

    @Inject
    private Account account;    

    @Test
    @Transactional
    public void createAccount() {
        accountRepository.save(account);

        assertEquals(1, account.getId()); // this assertion will be failed, until @Rollback(false) is used
    }
}

Ответы [ 2 ]

2 голосов
/ 24 декабря 2011

Если ваши ограничения не откладываются, и вы сбрасываете сеанс после вызова для сохранения, все будет записано в базу данных, и ограничения будут применены. Затем вы можете выполнить запросы и проверить, возвращены ли ваши объекты. Однако возвращенные сущности будут теми, которые хранятся в памяти сеансом.

Когда я действительно хочу проверить, что что-то сохраняется правильно, я обычно выполняю постоянство в одной транзакции (используя TransactionTemplate), а затем выполняю запросы, чтобы проверить, что все в порядке после принятия транзакции.

0 голосов
/ 20 октября 2013

Вы можете сделать комбинированный em.flush () и затем em.clear ().em.flush был описан выше.em.clear () отключит все сущности, известные в настоящее время контекстом.

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

Как можно надежно проверить обновления модуля сущности JPA в модульном тесте

...