Я бы разделил три разных сценария ios на собственные тестовые случаи. Аналогично этому:
@Test
void updateItem() throws Exception {
CatalogItems cat = new CatalogItems(1, "xxxx", "f");
ResponseEntity Res = Eservice.updateItemInDynamoDbTable(cat);
System.out.println(Res.getStatusCodeValue());
CatalogItems cat2 = Eservice.findById("1");
assertEquals(Res.getStatusCodeValue(), 201);
assertEquals(cat2.getAuthor(), cat.getAuthor());
assertEquals(cat2.getTitle(), cat.getTitle());
assertEquals(cat2.getId(), cat.getId());
}
@Test
void updateItemFailsWhenDestinationIsNotFound() {
CatalogItems cat = new CatalogItems(3, "xxx", "xxx");
Exception exception = assertThrows(ResourceNotFoundException.class, () -> {
ResponseEntity Res = Eservice.updateItemInDynamoDbTable(cat);
});
String expectedMessage = "ResourceNotFoundException";
String actualMessage = exception.getMessage();
assertTrue(actualMessage.contains(expectedMessage));
}
@Test
void updateItemFailsWhenIdIsNotAvailableAtDestination() {
CatalogItems cat = new CatalogItems(3, "xxx", "xxx");
Exception exception = assertThrows(NullPointerException.class, () -> {
ResponseEntity Res = Eservice.updateItemInDynamoDbTable(cat);
});
System.out.println(exception.getMessage());
assertNull(exception.getMessage());
}
Хорошей практикой является использование только кода, который фактически генерирует исключение в лямбде assertThrows. Таким образом, вы можете быть уверены, что этот код не работает.
Я бы также рекомендовал придерживаться соглашения об именовании Java, то есть иметь члены, переменные и параметры в нижнем регистре верблюда.