How Java developers should test their applications (RU)
summary
Argues that business logic belongs in services or event handlers and should be unit-tested with mocks (mentions Mockito and alternatives), while flat integrator services get integration or UI-backed coverage; demonstrates Spring MockMvc standalone controller tests, DB tests with in-memory H2 and DBUnit, embedded Redis/Cassandra units, and WebDriver page‑object UI tests (recommends Serenity). Shows CI-friendly timings (thousands of tests -> full build 2–3 minutes, regression 7–8 minutes), and promotes instrumentation and a testable Clock abstraction. Key rule: mock protocols not domain objects.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 2:18Business logic testing
- 17:30Mocks and usage
- 21:51MVC layer testing
- 39:17Database testing
- 57:17Object transformations and services
- 1:06:31Multithreading and testing
- 1:17:29UI testing with Selenium
- 1:28:25REST testing and tools
- 1:38:46File system testing
- 1:42:00Testing with clocks and dates
- 1:45:13Q&A
related talks
47mMicroservices Testing with Java
41mTesting done right: From bugs to brilliance
58mIntegration Testing from the Trenches
02h 58mOverview of Testing in Our Applications
55mUnit Testing Like a Pro - Towards a Testable Design
54mAutomated Tests: What Courses Won't Teach You
46mThe Good, The Bad, and The Stubbed: A Java Unit Testing Adventure
02h 36mTesting Java Microservice