У меня есть метод, который вызывает другой метод для извлечения данных и вставки его в базу данных, как я могу проверить этот метод в 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-объект для пользователя, но я не уверен, как проверить, вставлен ли пользователь в базу данных. пожалуйста помоги.
Здесь есть несколько указателей, но до этого вы должны быть уверены, что тестируемый код. Причина, по которой я говорю это, заключается в том, что это действительно заставит вас много реорганизовать ваш код.
Например, для кода ниже:
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();
}
}
вы можете протестировать следующее: -
Правильно ли создается строка запроса, т.е. Допустимый SQL, как ожидалось?
Должен ли метод никогда не вызывать исключение, поскольку мы хотим поймать все проверенные исключения?
Все ресурсы закрыты после завершения работы? например, в вашем методе соединение открыто, но никогда не закрывается.
Теперь из вышеперечисленных точек могут быть некоторые моменты с более высоким значением, например, обеспечение правильного построения запроса.
Таким образом, для этого должен быть извлечен код построителя запросов из этого метода, и теперь вы можете легко протестировать этот запрос в отдельном модульном тесте.
Аналогичным образом, вы захотите убедиться, что соединение закрыто после завершения работы. Следовательно, вы можете извлечь этот код в метод, который принимает запрос как параметр, открывать соединение, выполняет DB CRUD закрывает соединение и возвращает результат. И убедитесь, что вы не повторяете этот код все время разными способами.
Теперь отпустите указатели:
Если вы в любой момент подумаете, что внутри метода есть какой-то код, который не тестируется, пока этот код не станет частью метода. Пожалуйста, вытащите его на общедоступный/частный метод и протестируйте его.
Никогда не пытайтесь проверить постоянство БД как часть unit test
. Драйверы DB и т.д. Уже имеют свои собственные тесты и используются во всем мире.
Если вы считаете, что your method
должен быть проверен на то, называется ли он так много раз, как ожидалось (it what you want to test
). Это interaction based testing
Вы можете использовать насмешку (Mockito) и заглушить тестируемый метод, а затем утверждать, сколько раз метод должен быть вызван. См. Эту и эту ссылку.
Надеюсь, поможет!
Классы должны проверяться на предмет ожидаемого поведения.
Здесь тестирование типа возврата (даже если оно имело другую вещь как void
) не имеет смысла.
Ваш метод выполняет SQL-запрос.
Поэтому ваш unit тест должен утверждать ожидаемый побочный эффект для базы данных: вставка с ожидаемыми значениями.
Обратите внимание, что для проведения повторных и быстрых тестов вы должны использовать встроенные базы данных для модульного тестирования.