Как я могу проверить метод void, который вставляет запись в базу данных, используя Junit?

0

У меня есть метод, который вызывает другой метод для извлечения данных и вставки его в базу данных, как я могу проверить этот метод в Junit, поскольку этот метод ничего не получает? Может ли кто-нибудь предоставить мне пример этой ситуации?

public static void method(){ 
    User user = getUser();  
    try {
        String Query = "INSERT INTO users (USER_ID , Name) VALUES ("
         +user.getID()+","+user.getName()+")";

        Statement statement = conn.createStatement();
        statement.executeUpdate(Query);
    } catch (Exception e) {
        e.printStackTrace();
    }
}

Я думал использовать mock-объект для пользователя, но я не уверен, как проверить, вставлен ли пользователь в базу данных. пожалуйста помоги.

  • 1
    предполагая, что соединение с базой данных является внедренной абстракцией зависимости, вы можете смоделировать зависимость и убедиться, что она вызывается / вызывается при выполнении тестируемого метода. сделанный
  • 0
    «Мок» собирался быть моим ответом. Я также видел, как тестирование базы данных проводилось с реальной базой данных с отключенной частью ACID, так что транзакция может быть запущена, протестирована (изоляция отключена, чтобы вы могли прочитать результаты за пределами транзакции), а затем транзакция была свернута. назад вместо того, чтобы совершить возвращение тестовой базы данных в исходное тестовое состояние. Я забыл параметр, переданный в БД, чтобы перевести его в это состояние.
Показать ещё 1 комментарий
Теги:
unit-testing
testing
junit

2 ответа

1

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

Например, для кода ниже:

public static void method(){ 
    User user = getUser();  
    try {
        String query = "INSERT INTO users (USER_ID , Name) VALUES ("
         +user.getID()+","+user.getName()+")";

        Statement statement = conn.createStatement();
        statement.executeUpdate(query);
    } catch (Exception e) {
        e.printStackTrace();
    }
}

вы можете протестировать следующее: -

  1. Правильно ли создается строка запроса, т.е. Допустимый SQL, как ожидалось?

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

  3. Все ресурсы закрыты после завершения работы? например, в вашем методе соединение открыто, но никогда не закрывается.

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

Таким образом, для этого должен быть извлечен код построителя запросов из этого метода, и теперь вы можете легко протестировать этот запрос в отдельном модульном тесте.

Аналогичным образом, вы захотите убедиться, что соединение закрыто после завершения работы. Следовательно, вы можете извлечь этот код в метод, который принимает запрос как параметр, открывать соединение, выполняет DB CRUD закрывает соединение и возвращает результат. И убедитесь, что вы не повторяете этот код все время разными способами.

Теперь отпустите указатели:

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

  2. Никогда не пытайтесь проверить постоянство БД как часть unit test. Драйверы DB и т.д. Уже имеют свои собственные тесты и используются во всем мире.

  3. Если вы считаете, что your method должен быть проверен на то, называется ли он так много раз, как ожидалось (it what you want to test). Это interaction based testing

Вы можете использовать насмешку (Mockito) и заглушить тестируемый метод, а затем утверждать, сколько раз метод должен быть вызван. См. Эту и эту ссылку.

Надеюсь, поможет!

0

Классы должны проверяться на предмет ожидаемого поведения.
Здесь тестирование типа возврата (даже если оно имело другую вещь как void) не имеет смысла.

Ваш метод выполняет SQL-запрос.
Поэтому ваш unit тест должен утверждать ожидаемый побочный эффект для базы данных: вставка с ожидаемыми значениями.
Обратите внимание, что для проведения повторных и быстрых тестов вы должны использовать встроенные базы данных для модульного тестирования.

  • 1
    Я лично не согласен! Взаимодействие с базой данных никогда не должно быть проверено там в модульном тестировании и должно быть проверено. До тех пор, пока не будет настроенной логики для взаимодействия с базой данных. Почему кто-то хотел бы проверить очевидную вещь, которая будет работать в модульном тестировании? Существуют и другие тесты, например E2E и интеграционные тесты, чтобы убедиться, что такие интеграции работают нормально.
  • 0
    Спасибо, чтобы выразить свое мнение, несмотря на расхождения:) Интеграционные тесты предназначены для тестирования интеграции между компонентами. Поскольку я кодирую компонент, который выполняет запросы, я также хочу проверить его унитарно. Обратите внимание, что быстрое модульное тестирование является одной из основных целей встроенных баз данных.
Показать ещё 2 комментария

Ещё вопросы

Сообщество Overcoder
Наверх
Меню