我有一個服務：
@Service
@Transactional
@RequiredArgsConstructor
public class BookService {
private final BookRepository bookRepository;
public Book findOne(Long id) {
return bookRepository.findById(id).orElse(null);
}
public Book getOne(Long id) {
return bookRepository.findById(id)
.orElseThrow(() -> new BadRequestAlertException("entity-not-found", ("Entity with id: " id " not found!")));
}
public List<Book> getAll() {
return bookRepository.findAll();
}
public Book save(Book book) {
return bookRepository.save(book);
}
}
我已經為資料庫（BookRepository）和控制器層（使用 BookService 的 BookController）撰寫了集成測驗。我在任何地方都找不到服務層集成測驗的示例。如果我正確撰寫單元測驗，是否有任何用例可以為其撰寫集成測驗？據我所知（這不是規則，而是常見用例）：
- 控制器 - 集成測驗
- 服務 - 單元測驗
- 存盤庫 - 集成測驗
uj5u.com熱心網友回復：
好的，這就是你可以想到的方法......
為 撰寫單元測驗是零意義的
repositories，它們只被集成測驗覆寫。選擇使用in-memory DBDocker 容器中的 DB 還是適當的 DB 取決于具體情況，但通常我會選擇 Docker 容器中的 DB，因為 H2（即使使用postgres方言）不是PostgresDB的完整副本。因此，測驗可能會運行，但應用程式將在生產中崩潰。對于
controllers，您可能希望混合使用單元測驗和集成測驗。使用MockMvc該類測驗大多數控制器內容。集成測驗涵蓋了最關鍵的場景，以測驗整個垂直（3 層）功能切片。現在我們進入到
services部分。如果你的服務有復雜的業務邏輯，你想驗證它，那么它必須被單元測驗覆寫，這樣你就可以在很少的時間內做大量的檢查。此外，通過集成測驗覆寫一些最基本的場景是有意義的。特別是在您的情況下，服務層內的業務邏輯非常簡單，因此我只進行集成測驗。如果它變得更復雜，您還可以添加一些單元測驗，在其中模擬存盤庫類，以獲得極快的測驗時間，并且能夠在不減慢CI專案中每個人的管道的情況下進行大量檢查。
一般來說，盡量遵循測驗金字塔模式，并使用Spring Boot 生態系統提供的最好的測驗庫。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/351817.html
上一篇：盡管沒有問題publicstaticint沒有回傳任何東西
下一篇：如何從Java程式打開IE