Now that we have modern test frameworks (Kotest, T...
# testc
CLOVIS
10/28/2026, 10:13 AMNow that we have modern test frameworks (Kotest, TestBalloon, Prepared…) it's become easier than ever to have tons of very small tests. This is good because it allows each test to have a single responsibility and makes it easier to test a large amount of edge cases.
However, tests are also useful as automated specification of the behavior of the application. When there are hundreds or thousands of tests for a single feature through its individual edge cases, it's difficult to get a quick overview and mental model of what the feature actually is.
What's your solution to be able to easily review the coverage of a feature, find missing edge cases, or just understand what a feature does based on its tests?
m
Mario Palka
10/28/2026, 12:19 PMI dont have any tool for retrospective inspection of feature coverage. The best solution here is not to have the problem đŸ¤“
For that I changed my workflow to ATDD - there is no feature production code without spec test (high-level test, when your app plays black-box role)
Spec test are written in as much natural language as possible, due to Kotlin its much easier than in any other language đŸ‘‡
Mario Palka
10/28/2026, 12:21 PMupdate: its not good to write spec test for edge cases (tests become very slow in CI), then you need to go deeper and write lower level tests, like unit tests or use case tests
j
Javier
10/29/2026, 9:11 AMPersonally, I think that unit tests should be little exceptions in apps (so, in features). They are good for libraries.
Most app tests should be e2e or integration tests if e2e are too slow.
Integration tests can be a huge chain, for example, testing a viewmodel or presenter with real dependencies except the latest one (that means, for example, replacing only Ktor engine with the mock engine and SQLDelight driver with the memory driver)
m
Mario Palka
10/29/2026, 9:24 AM@Javier I agree. It depends on requirements - you can have one acceptance (black-box) test and no other xUnit tests (happy-path scenario)
There is very good presentation about aiming to maximum TDD efficiency. What you call integration they call use case. The main idea is to focus on behavior (features).
e
Eugen Martynov
10/29/2026, 1:55 PMSimilar to Mario approach - context or nested unit tests. Possible with junit and test ballon. (Prepared - something to check TIL).