DEV Community: Tiberiu Tofan

Your AI Writes Junk, and You Pay for It Twice

Tiberiu Tofan — Mon, 15 Jun 2026 12:45:21 +0000

Last week an agent wrote me around ten tests for a function. Two of them were useless. Not wrong, exactly: they re-checked the same branch, asserted things the type system already guaranteed, and added nothing a reviewer would keep. I paid output tokens to generate them, then input tokens to carry them in context on every turn after. The model had no reason to delete them. Neither did the company billing me by the token.

That's the whole problem in one file. We pay for AI by the unit it produces, not by the value it delivers. Not a scam, not lazy, just misaligned. And the misalignment leaks much further into your codebase than you'd expect. Let me show you.

The tax

The marginal cost of a bad token equals the marginal cost of a good one, so a model billed per output token has a built-in pull toward saying more. Imagine paying programmers per keystroke and acting surprised when the functions get long. My two useless tests are a small example of this. Reasoning models make it worse: an internal chain of thought you never read but pay for, so a response showing five hundred visible tokens can quietly burn several thousand.

The community already feels this. Caveman, a Claude Code skill with around 70k stars, makes the agent talk like a caveman ("why use many token when few token do trick") and cuts around 65% of output tokens. Think about that for a second: we built tooling to make the agent grunt, because the meter made full sentences a cost problem.

Worth knowing: "cheaper per token" often means "more expensive per task." OckBench calls this the overthinking tax. Smaller models burn absurd token counts trying to imitate complex reasoning without getting there, and the benchmark's most extreme result is an open model matching a frontier model at 75% accuracy while spending 26 times the tokens, 42,243 versus 1,603. The headline price is a trap.

An arXiv paper, Is Your LLM Overcharging You?, goes further: under per-token pricing, providers have a financial incentive to misreport token counts, and users can't prove, or even know, they're overcharged. The authors' fix is telling: pay per character, a unit the user can count. Even the academics fall back to the most verifiable unit available. Hold that thought.

Caragiale saw all of this coming in 1884. In his comedy A Lost Letter, the police chief Pristanda bills the town for forty-four flags and hangs about a dozen. When questioned, he counts them out loud: two at the prefecture, two in the market square, two at the town hall, one at the boys' school, one at the girls' school, one at the hospital, two at the cathedral... and then, two at the prefecture again, padding the tally back up toward the dozen-odd that were really there. When the prefect laughs that he already counted those, Pristanda speeds up, recounts everything with even bolder arithmetic, lands on forty-four exactly, and offers that maybe the wind took down one or two. He even has the provider's defense ready: big family, small salary. You know the modern version: big models, expensive GPUs. The trick only got exposed because Zoe rode through town and counted the flags herself. Remember Zoe.

It deforms your architecture

The pricing model doesn't stay on the invoice. It climbs out and draws your architecture diagram. You cap history, cache hard, route cheap paths to small or local models, keep reasoning models off the hot path. In a value-aligned world half of these decisions wouldn't exist.

I felt this building httptape, a Go library for recording, redacting, and replaying HTTP traffic. When the API on the other end is an LLM, every test run is metered. Run the suite a hundred times a day and you've paid a hundred times to assert the same thing. So you record once, replay from a tape, and your tests stop touching the paid boundary. Useful engineering, yes. Also a structure I built because of pricing pressure, not because a user needed it. The economics draw the boxes and you label them afterward.

"So just charge for outcomes"

This is already happening. Intercom's Fin charges about a dollar per resolved conversation, Zendesk prices per automated resolution, Sierra built a company on it. It shows up where the outcome is cheap to define and cheap to verify. The trouble starts on code. I had three fixes in mind, and watching each one break taught me more than any of them working would have.

First: charge only if it compiles. This one mostly holds. Compilation is binary, cheap to check, impossible to argue with.

Second: charge only if the tests pass. A while back I joined a team that inherited a codebase from an outside group. One handover condition was 80% test coverage, a clean contractual outcome. The number was met. Most of the tests had no assertions at all. Nobody had to cheat: coverage measures which lines a test touches, never whether it verifies anything, and the moment it became the graded number it stopped describing what we cared about. Pay an agent against a green suite and the cheapest path to green is what you'd expect: a test that asserts nothing, an assertion quietly weakened, a hard case skipped with a convincing comment.

And gaming is only the cynical version. When the same agent writes the code and then the tests, the tests are derived from the implementation, bugs included. A wrong boundary condition doesn't get caught, it gets asserted, and now it's green and regression-protected. Colleagues of mine built a skill pushing agents to do TDD, and I keep asking a question I can't answer: does test-first carry any value over to generated code? For humans, TDD's real product was never the tests, it was design pressure on the author. Whether that survives when one model writes both sides of the contract in one go, I haven't seen anyone demonstrate. We're pricing against a signal we haven't even validated. We've all seen the human version anyway, the automatic "LGTM" on a PR nobody read. A green light is cheap to emit and expensive to verify, so it stops meaning anything.

Third: cut the price when the agent ignores AGENTS.md, which it does constantly. My instructions file says "always use the latest library versions" and "when blocked, stop and ask for guidance, don't try alternative approaches without approval." Copilot once hit a failing test, misread the error output, and started downgrading libraries to make it pass: both rules broken in one loop, chasing the wrong problem. I paid tokens for every step of that loop, and then more tokens to undo it. The disobedience itself is billable. So cutting the price for ignored instructions sounds fair, but you can only subtract for violations you can mechanically detect. "Never use !!" is a lint rule. "Keep the domain pure, respect the hexagon" is not. The instructions I care about most are the ones I can't auto-verify, which is exactly why they get ignored and exactly why I can't price the violation.

The verifiability gradient

Lay the three fixes side by side and a pattern shows up underneath them:

Pricing can only attach to the left end. Real value lives on the right. Remember pay-per-character? That's the far left edge, the most countable unit there is. And providers aren't being lazy: their costs really are quantitative, GPU-seconds and tokens, while outcome pricing asks them to pay for the times the model fails. A rational provider only takes that bet where the outcome is cheap to define and hard to fake, which is why your support-ticket vendor can and your model API can't.

Token pricing won because the countable thing is both the easiest to meter and the easiest to inflate, while the valuable thing sits just past the edge of what we can compute.

What's missing

The unlock isn't a billing setting. It's whoever builds the layer that can score the right end of that gradient, and that layer has one hard constraint: the thing being measured can't report its own meter. Zoe didn't ask Pristanda how many flags he hung. She counted them from the carriage. VibeWarden, the security sidecar I've been building, runs on the same stubborn rule: watch the boundary, don't trust the actor. A verifier for AI-generated code has to work the same way, sitting beside the agent and checking the build, the suite, the architecture, and the rules independently, because anything self-reported is worth as much as an unread LGTM. I feel strongly enough about that last part that I built lgtm-buzzer, a browser extension that quizzes you on the diff before letting you approve a PR. The green light should cost something.

That's the next thing I want to build: an external referee that measures a little further up the gradient than "it compiled," while being honest that the very top, whether the design is actually good, stays out of reach for any tool, mine included. And one experiment I want to run on the way: same tasks, code-first versus test-first agents, seeded bugs, and a count of which flow's tests actually catch them. That's the next piece.

Until then, a question for you: would you pay per outcome for generated code? And what signal would you trust to verify it?

All You Need Is Lambdas: Java Tests Without a Mocking Framework

Tiberiu Tofan — Thu, 07 May 2026 14:34:05 +0000

Most Java developers have written something like this. Maybe recently.

@Test
void should_categorize_new_transactions() {
    final var mockRepository = Mockito.mock(CategorizedTransactionRepository.class);
    final var mockMerchantDirectoryService = Mockito.mock(MerchantDirectoryService.class);
    final var categorizer = new TransactionCategorizer(mockRepository, mockMerchantDirectoryService);
    final var message = createSampleTransactionMessage();

    Mockito.when(mockMerchantDirectoryService.getCategoryForMerchant(message.mcc()))
            .thenReturn(new MerchantInfo(message.mcc(), "Transportation"));
    Mockito.when(mockRepository.findByTransactionId(message.transactionId()))
            .thenReturn(Optional.empty());
    Mockito.when(mockRepository.save(Mockito.any()))
            .thenAnswer(invocation -> {
                var ct = (CategorizedTransaction) invocation.getArgument(0);
                ct.setId(1L);
                return ct;
            });

    final var result = categorizer.categorize(message);

    Assertions.assertEquals(1L, result.getId());
    Assertions.assertEquals(message.transactionId(), result.getTransactionId());
}

A unit test for a small piece of business logic, with mocks for the things it talks to. Mockito setup, a few when().thenReturn() calls to stub behavior, an assertion at the end. It works, and it's been the default in Java testing for almost two decades. Most teams have hundreds of these tests. Some have thousands.

Here's the same test, written differently:

@Test
void should_categorize_new_transactions() {
    final var transaction = createSampleTransaction();
    final var categorizedTransactionId = new CategorizedTransactionId(1L);
    final var categorizer = TransactionCategorizer.create(
            (categorizedTransaction) -> categorizedTransaction.withId(categorizedTransactionId),
            (transactionId) -> Optional.empty(),
            (mcc) -> new ExpenseCategory("Transportation")
    );

    final var result = categorizer.categorize(transaction);

    Assertions.assertEquals(categorizedTransactionId, result.id());
    Assertions.assertEquals(transaction.transactionId(), result.transactionId());
    Assertions.assertEquals("Transportation", result.expenseCategory().value());
}

Same assertions, same correctness, no Mockito. Three lambdas where the original had three when().thenReturn() blocks. No @Mock, no verify(), no ArgumentCaptor. The actual behavior under test isn't buried under setup anymore; it sits in the middle of the test where it belongs.

The change isn't to the test. It's to the interface the test had to mock. That's what the rest of this article is about: where the Mockito ceremonies came from in the first place, and what kind of interface lets you delete them.

The interface that caused this

Here's the repository being mocked in the first test:

@Repository
public interface CategorizedTransactionRepository
        extends JpaRepository<CategorizedTransactionEntity, Long> {

    Optional<CategorizedTransactionEntity> findByTransactionId(String transactionId);

    List<CategorizedTransactionEntity> findByClientIdAndExpenseCategory(
            String clientId, String expenseCategory);

    @Query("""
            SELECT new fvf4j.demo.domain.CategoryBudget(t.expenseCategory, SUM(t.amount))
            FROM CategorizedTransactionEntity t
            WHERE t.clientId = :clientId
            GROUP BY t.expenseCategory
            """)
    List<CategoryBudget> findBudgetsByCategory(@Param("clientId") String clientId);

    @Query("""
            SELECT DISTINCT t.expenseCategory
            FROM CategorizedTransactionEntity t
            WHERE t.clientId = :clientId
            """)
    List<String> findDistinctExpenseCategoriesByClientId(@Param("clientId") String clientId);
}

Nothing unusual about it. Four query methods plus everything Spring Data adds through JpaRepository: save, findById, findAll, delete, count, existsById, the paging variants, the example-matching variants, the batch operations. A few dozen methods in total, most of which the application doesn't use, but they come along for the ride because they're part of the contract.

This is the interface every Java codebase has some version of. It's reasonable. It's idiomatic. Spring's documentation recommends it, the Spring Boot tutorial uses it, every JPA tutorial since 2014 has shown it. Why settle for one responsibility when you can have them all in one interface?

The problem is what consumers of this interface end up depending on. TransactionCategorizer uses exactly two methods from it: findByTransactionId and save. To compile, it depends on the entire repository interface. To test, it leans on a framework that can stand in for that whole surface, which is what Mockito is doing in the first test. The two methods the consumer actually uses are the two it stubs. The dozens it doesn't use don't show up in the test setup, but they're still there at compile time. Every method on that interface is part of the consumer's surface area, even when it's silent.

This is the Interface Segregation Principle in its most concrete form. Consumers shouldn't depend on methods they don't use. When they do, the test setup pays the cost. If only that.

The interface ties the consumer to JPA. It dictates the contract from the persistence side rather than the domain. And the cost I see most often in production isn't even the testing pain. It's that dependencies like this make it easy for developers to add yet another responsibility to the same service, because the wiring is already there. I've watched a four-method service become a sixteen-method one over a year because nobody had to add a new dependency to add a new feature.

The fat interface invites the fat service.

Splitting the boundary

The repository in the previous section answers a question the persistence layer is asking: "what queries can you run against this entity?" The answer is shaped by JPA's mechanics: methods named after the database access pattern, return types tied to JPA entities, query annotations embedded in the interface.

A consumer like TransactionCategorizer is asking different questions: "given a transaction, can someone tell me whether I've already categorized it, and can someone save the result?" Two questions. Two methods. Nothing about JPA, nothing about entities, nothing about the dozens of other things the repository can do.

When the consumer's question and the persistence layer's answer are mediated by the same interface, the consumer ends up depending on the answer's full surface. The fix is to give the consumer its own interface, one shaped to its question rather than to the implementation that happens to satisfy it.

Here's one of those interfaces:

@FunctionalInterface
public interface FindByTransactionId {
    Optional<CategorizedTransaction> findBy(TransactionId transactionId);
}

A single method, named after what the consumer wants to do. No JpaRepository parent, no JPA entities in the signature. The return type is the domain's CategorizedTransaction, not the persistence layer's CategorizedTransactionEntity. The interface tells you exactly what it offers and nothing else.

A few things about the naming worth pausing on. The interface is FindByTransactionId, not TransactionFinder or TransactionQueryService. It's a verb, not a noun. That's deliberate.

Noun-named interfaces describe what the type is. Verb-named interfaces describe what the type does. For functional interfaces, "what it does" is the more honest description, because there's only one thing it does. Calling it a "Service" or "Repository" or "Finder" borrows weight from those patterns to dress up what is essentially a function.

Verb names also force the question of consumer perspective. FindByTransactionId names the action the consumer wants to take. TransactionRepository names the implementation that happens to be available. The first puts the domain in charge of the contract; the second lets the persistence layer dictate it. That's the dependency-direction shift that ports-and-adapters architectures are built around, and it starts at the name.

The parameter and return types are also worth a glance. TransactionId instead of String, ExpenseCategory instead of String, CategorizedTransaction instead of an opaque entity. That's a separate architectural discipline. Making domain types unambiguous at the boundary deserves its own treatment in another post. For now, the segregation argument and the value-object argument pull in the same direction: both are about making the boundary speak the domain's language rather than the implementation's.

The rest of the segregated interfaces follow the same pattern:

public interface CategorizedTransactionPorts {

    @FunctionalInterface
    interface SaveCategorizedTransaction {
        CategorizedTransaction save(CategorizedTransaction categorizedTransaction);
    }

    @FunctionalInterface
    interface FindByTransactionId {
        Optional<CategorizedTransaction> findBy(TransactionId transactionId);
    }

    @FunctionalInterface
    interface FindByClientIdAndExpenseCategory {
        List<CategorizedTransaction> findBy(ClientId clientId, ExpenseCategory expenseCategory);
    }

    @FunctionalInterface
    interface FindBudgetsByCategory {
        List<CategoryBudget> findBudgetsByCategory(ClientId clientId);
    }

    @FunctionalInterface
    interface FindExpenseCategoriesByClient {
        List<ExpenseCategory> findExpenseCategoriesBy(ClientId clientId);
    }
}

Five interfaces where the original repository had one. Each is a single method. Each is named after the action the consumer takes, not the persistence pattern that satisfies it. None of them inherit from anything Spring-related; the dependency on JPA stays on the implementation side, which is where it belongs.

Worth noting: CategorizedTransactionPorts itself isn't a port. It's an outer interface used as a namespace, grouping ports that belong to the same boundary. Java doesn't allow multiple public top-level types in one file, and a class with a private constructor would feel heavier than this needs to be. The outer interface is just a logical container. CategorizedTransactionPorts.FindByTransactionId reads as "the find-by-transaction-id port that belongs to the categorized-transaction boundary," which is the actual relationship.

The TransactionCategorizer now declares dependencies only on the ports it actually uses: SaveCategorizedTransaction and FindByTransactionId. The other three exist for other consumers. None of them know or care about each other.

Where the implementations live

A common concern when splitting fat interfaces into many functional interfaces is that the number of implementation classes will explode. It doesn't. A single adapter can implement multiple ports, and usually does:

public class CategorizedTransactionRepositoryAdapter implements
        SaveCategorizedTransaction,
        FindByClientIdAndExpenseCategory,
        FindByTransactionId,
        FindExpenseCategoriesByClient,
        FindBudgetsByCategory {

    private final CategorizedTransactionJpaRepository jpaRepository;

    public CategorizedTransactionRepositoryAdapter(CategorizedTransactionJpaRepository jpaRepository) {
        this.jpaRepository = jpaRepository;
    }

    @Override
    public CategorizedTransaction save(CategorizedTransaction categorizedTransaction) {
        return jpaRepository
             .save(CategorizedTransactionEntity.valueOf(categorizedTransaction))
                .toDomain();
    }

    @Override
    public List<CategorizedTransaction> findBy(ClientId clientId, ExpenseCategory expenseCategory) { /* ... */ }

    @Override
    public Optional<CategorizedTransaction> findBy(TransactionId transactionId) { /* ... */ }

    @Override
    public List<ExpenseCategory> findExpenseCategoriesBy(ClientId clientId) { /* ... */ }

    @Override
    public List<CategoryBudget> findBudgetsByCategory(ClientId clientId) { /* ... */ }
}

One adapter, five ports. The class delegates each method to the original Spring Data repository, now renamed CategorizedTransactionJpaRepository to make its role explicit. The fat interface didn't disappear in the refactor; it got demoted to an implementation detail. The adapter also handles translation between persistence-side and domain-side types. CategorizedTransactionEntity from the JPA layer becomes CategorizedTransaction in the domain, and the mapping is the adapter's responsibility, which keeps it out of the consumer's signatures.

Spring's wiring is straightforward. The adapter is registered as a bean that implements every port interface. Anywhere a domain consumer asks for a FindByTransactionId or a SaveCategorizedTransaction, Spring resolves it to this adapter because the adapter implements the port. The consumer doesn't know whether it's getting a Spring bean, a test lambda, or something else, and that's the point.

The tradeoff is real, even if the class explosion isn't. More small contracts means more names to know, more imports, more places a method might live. Whether that's a net win depends on what your team struggles with more: oversized dependencies that drag too much into every test, or navigating a wider surface of small types. For long-lived domains with multiple consumers, the segregation usually pays off. For a three-controller CRUD app, it probably doesn't.

Why the second test works

The segregated ports are all single-method interfaces. That means anywhere the consumer expects a port, you can pass a lambda. The consumer doesn't know the difference. As far as TransactionCategorizer is concerned, it received an implementation of SaveCategorizedTransaction and is calling it. Whether that implementation is a Spring bean wired up at runtime or a one-line lambda passed by a test, the call site looks the same.

That's the property the test was using:

final var categorizer = TransactionCategorizer.create(
        (categorizedTransaction) -> categorizedTransaction.withId(categorizedTransactionId),
        (transactionId) -> Optional.empty(),
        (mcc) -> new ExpenseCategory("Transportation")
);

Three lambdas, three ports. Each lambda satisfies the contract of one port. Their order matches the order of the constructor parameters, which means a reader doesn't even need names to follow what's happening. The first lambda is the save behavior. The second is the find. The third is the merchant category lookup.

Compare what the Mockito version had to do. The most awkward part was simulating the database's "assign an id on save" behavior:

Mockito.when(mockRepository.save(expectedTransaction))
        .thenAnswer(invocation -> {
            var ct = (CategorizedTransaction) invocation.getArgument(0);
            ct.setId(1L);
            return ct;
        });

Capture the argument, cast it, mutate it, return it. Five lines of dance to express what the lambda version expressed in one:

(categorizedTransaction) -> categorizedTransaction.withId(categorizedTransactionId)

Take the input, return a copy with an id assigned. No casting, no capture, no framework.

Worth being precise about what these lambdas are. They're test doubles — specifically, stubs. They return canned values for the test's purposes, nothing more. The article's argument is narrower than "stop using Mockito": it's that when ports are narrow, lambdas are a better tool than a framework for stubbing. Verification is a different question. If a test genuinely needs to assert that a method was called, with which arguments, in which order, then a mocking framework's verify(...) is the right tool — better than hand-rolling countdown latches and counters. Most tests don't need that. The ones that do still benefit from segregated ports, because the verification is scoped to a single port instead of a fat repository.

The lambda version uses result.id() and withId(...) instead of result.getId() and setId(...). CategorizedTransaction is no longer a mutable JPA entity; it's an immutable record. That's a real change in the consumer code, and it's a consequence of the boundary fix. When persistence-side types stopped leaking into the consumer's signatures, the consumer was free to use a domain type that didn't need to be a JPA entity.

The test gets shorter and the consumer code gets cleaner, but neither was the goal. Both came out of giving the boundary the right shape.

And in Kotlin

If your codebase is Kotlin, the same pattern gets a small set of upgrades worth knowing about.

fun interface replaces @FunctionalInterface and reads as a more honest declaration. Kotlin calls these SAM types, for "single abstract method." The compiler enforces the same constraint either way, but the keyword tells the reader at a glance that this type exists to be passed as a function.

fun interface SaveCategorizedTransaction {
    operator fun invoke(transaction: CategorizedTransaction): CategorizedTransaction
}

Two things changed. The interface is fun interface, and the method is named invoke and marked operator. The first is just nicer syntax. The second is the more interesting choice: any object with an operator fun invoke can be called like a function. So at the consumer's call site, the port reads as a plain function call:

val saved = saveCategorizedTransaction(transaction)

Not saveCategorizedTransaction.save(transaction), not saveCategorizedTransaction.execute(transaction). Just the call. Whether the implementation is a class, a lambda, or a method reference, the call site looks identical. The fact that there's an interface in the middle becomes invisible.

There's also a small organizational difference. The Java version grouped its ports inside an outer CategorizedTransactionPorts interface as a namespace. That was a workaround for a real Java constraint: one public top-level type per file. To keep five related ports visible together, the Java version needs either a containing type or five separate files sitting next to each other in a package.

Kotlin doesn't have that constraint. A single file can declare multiple top-level public types, so all five ports live together in one file with no scaffolding:

package fvf4k.demo.domain.spi

fun interface SaveCategorizedTransaction { /* ... */ }
fun interface FindByTransactionId { /* ... */ }
fun interface FindByClientIdAndExpenseCategory { /* ... */ }
fun interface FindBudgetsByCategory { /* ... */ }

In tests this means even less ceremony. Trailing lambda syntax shrinks the construction further:

val categorizer = TransactionCategorizerService(
    findByTransactionId = { Optional.empty() },
    saveTransaction = { it.copy(id = testId) },
    resolveExpenseCategory = { ExpenseCategory("Transportation") }
)

Named parameters, lambdas with implicit it, no (parameter) -> boilerplate. The parameter names match the port names: findByTransactionId, saveTransaction, resolveExpenseCategory. The verb-naming discipline from earlier carries through to the construction site. The same test in Kotlin is a few characters shorter than the Java version, but the deeper win is conceptual: at every call site and every test site, the port is indistinguishable from a function, because at that point it is one.

Wrapping up

The article's hook was Mockito ceremony, and the immediate payoff is real: a test that doesn't need a mocking framework, a consumer that depends only on what it actually uses, a boundary that speaks the domain's language. Those are the practical wins. They're worth having on their own.

The architectural win sitting underneath is the more durable one. Naming ports after the action a consumer wants to take, instead of after the type that happens to satisfy them, flips the dependency direction. The persistence layer stops dictating the consumer's contract; the consumer dictates its own. Functional interfaces and lambdas are the small mechanism that makes this practical in a language with classes, but the choice that matters is the one made at the name. FindByTransactionId and TransactionRepository declare different things about who's in charge of the boundary, and by extension, of the design.

Frameworks are tools. They shouldn't be the ones writing your architecture.

None of this is new. Interface Segregation has been the I in SOLID for a long time. What's worth seeing here is the principle at its limit: not just smaller interfaces, but segregation taken seriously enough to shape the boundary itself.

There's a fuller version of this argument in the project the article's examples come from. It's a refactor of the same domain done twice, in Java and Kotlin, with hexagonal architecture, ArchUnit-enforced layer rules, value objects, and explicit failure handling. The Kotlin version uses Arrow's Raise for typed errors, which is its own architectural beat and a topic I want to come back to.

tibtof / fun-vs-framework

Demo project for my talk Own Your Design: Functional Principles vs the Framework

Own your design: functional principles vs the framework

Demo project to showcase the refactoring of a Spring Boot application from a layered architecture to a hexagonal architecture. The main branch contains the refactored solution. There are also individual branches for each architectural approach: layered and hexagonal, with a PR that highlights the changes.

To better understand the context I recomend watching my talk and going over the slides.

View on GitHub

The talk this code supports, Own Your Design: Functional Principles vs the Framework, walks through the full refactor with slides and animated examples. The recording and slides are at https://tibtof.dev/own-your-design/.

If you've worked on a Java or Kotlin codebase where a small number of methods on a fat repository ended up costing you a disproportionate amount of test setup, I'd be curious to hear about it in the comments. Most of us have the same scars. What worked for your team?

Sleep, Sort, Repeat: Testing Kotlin Coroutines with Virtual Time

Tiberiu Tofan — Tue, 28 Apr 2026 12:03:40 +0000

How long do you think this test takes to run?

@Test
fun `sleep sort should sort a list correctly`() = runTest {
    val unsorted = (1..100_000).map { Random.nextInt(0, Int.MAX_VALUE) }

    val sorted = unsorted.sleepSort()

    assertEquals(unsorted.sorted(), sorted)
}

It sorts 100,000 random integers (up to Int.MAX_VALUE) using Sleep Sort — an algorithm where each element waits in its own coroutine for a number of seconds equal to its value, then emits itself. A single element of Int.MAX_VALUE would take about 68 years to sleep through.

The test passes in about a second. Not a trick — kotlinx-coroutines-test is doing something genuinely clever, and it's worth knowing about whether or not you ever sort anything by sleeping. Let me show you.

What is Sleep Sort?

Sleep Sort is the kind of algorithm you find on a wiki at 1am and immediately want to implement. Start a task per element, have each one sleep for a duration proportional to its value, then collect the emissions in order. Smaller values wake up first, larger values wake up later, so the output comes out sorted.

It's a terrible sorting algorithm — but a fun fit for Kotlin coroutines. Coroutines are cheap (launching 100,000 of them is fine), delay is suspending rather than blocking (a suspended coroutine occupies no thread), and kotlinx-coroutines-test can fast-forward through delays. That last part is what makes the test above possible.

The implementation

suspend fun List<Int>.sleepSort(): List<Int> = coroutineScope {
    val sorted = Channel<Int>(size)

    launch {
        map { i ->
            launch {
                delay(i.seconds)
                sorted.send(i)
            }
        }.joinAll()
        sorted.close()
    }

    sorted.consumeAsFlow().toList()
}

For each element we launch a coroutine that delays for that many seconds, then sends the value into a channel (buffered to size so sends never suspend). An outer launch waits for all of them to finish, then closes the channel. Meanwhile consumeAsFlow().toList() is already collecting — elements arrive in delay-order, which is sorted order.

A small note on the API: this is restricted to non-negative integers, but not for the reason you'd expect. delay returns immediately for non-positive durations rather than throwing, so negative inputs all race to the channel at once and produce silently wrong output. A defensive version would start with require(all { it >= 0 }). Worth knowing about — sometimes a tolerant standard library hides a bug rather than preventing one.

(The repo has more on the implementation — the role of the outer launch, and what coroutineScope does for free. Linked at the end.)

Running it for real

First, let's see the algorithm work in real time:

suspend fun main() {
    val unsorted = listOf(5, 1, 3, 2, 1, 2, 3, 4)
    val (sorted, duration) = measureTimedValue { unsorted.sleepSort() }
    println("It took $duration to sort $sorted")
}

measureTimedValue runs a block, returns its result, and tells you how long it took — pleasant for this kind of thing.

It took 5.040657167s to sort [1, 1, 2, 2, 3, 3, 4, 5]

Five seconds for a list of eight integers. The result is sorted, and the runtime is bounded by the largest element, because that's the last coroutine to wake up.

Now think about that test from the top of the post: 100,000 random integers, each potentially up to Int.MAX_VALUE. With that many uniformly random values you're virtually guaranteed at least one above two billion, and the largest element drives the runtime — so the test should take decades. It runs in a second. So what's going on?

Virtual time

The trick is that runTest, from kotlinx-coroutines-test, uses virtual time:

@Test
fun `sleep sort should sort a list correctly`() = runTest {
    val unsorted = (1..100_000).map { Random.nextInt(0, Int.MAX_VALUE) }

    val (defaultSortResult, defaultSortDuration) = measureTimedValue {
        unsorted.sorted()
    }
    val (sleepSortResult, sleepSortDuration) = measureTimedValue {
        unsorted.sleepSort()
    }

    assertEquals(defaultSortResult, sleepSortResult)
    println("Default sort duration: $defaultSortDuration")
    println("Sleep sort duration: $sleepSortDuration")
}

Same sleepSort, same 100k integers, same delay(i.seconds) calls inside — but inside runTest, those delays don't cost real time:

Default sort duration: 45.769750ms
Sleep sort duration: 1.191051583s

Stdlib's sorted() still wins by a comfortable margin (it should, it's a real sorting algorithm), but the interesting number is the second one. Sleep sort, an algorithm whose runtime is theoretically bounded by the largest input value in seconds, finishes in 1.2 seconds for 100,000 random integers. That second is real CPU spent shuttling 100,000 coroutines through the scheduler — none of it is simulated delay.

What runTest does is swap in a TestCoroutineScheduler (paired with StandardTestDispatcher) with a virtual clock. When a coroutine inside the block calls delay(i.seconds), the scheduler doesn't actually sleep — it parks the coroutine in a queue keyed by its virtual wake-up time, then runs whatever's ready right now. When nothing's ready, it advances the virtual clock to the next-soonest wake-up and resumes that coroutine. Repeat until everything's done.

The relative ordering of delays is preserved (a 1-second delay still finishes before a 2-second one), but neither costs you real time. It's a great fit for testing time-dependent coroutine code without sitting around watching the test run.

Wrapping up

Sleep sort is a joke. runTest and virtual time are not. The joke was a useful excuse to look at how kotlinx-coroutines-test lets you write tests for time-dependent coroutine code that finish in milliseconds instead of years.

The same technique applies anywhere time is the dependency: retry-with-backoff, polling, debounce, scheduled jobs — anywhere a test would otherwise have to wait for something to happen.

If you want to dig deeper — the implementation details, what happens at the edges (nanoseconds, milliseconds, scaling to millions), and the cases where virtual time will quietly lie to you — there's a "Going deeper" section in the repo's README that picks up where this article leaves off:

tibtof / kotlin-sleep-sort

Sleep Sort implemented in Kotlin with coroutines and virtual time

kotlin-sleep-sort

Support code for Sleep, Sort, Repeat — an article on the sleep sort algorithm and how to test coroutines.

What it does

List<Int>.sleepSort() is a suspend extension that "sorts" a list of non-negative integers by launching one coroutine per element, delaying each by a duration proportional to the value, and collecting the results in arrival order through a Channel.

val sorted = listOf(5, 1, 3, 2, 4).sleepSort()
// → [1, 2, 3, 4, 5]

Each element waits value.seconds before being emitted, so on a real dispatcher the wall-clock cost grows with the largest element. The interesting part is what coroutines and runTest let you do about that — see the article.

Build & run

Requires JDK 21+ (the toolchain will fetch one via foojay if needed).

./gradlew build       # compile + test
./gradlew run         # not configured by default — use

…

View on GitHub

If you've hit a case where virtual time gave you false confidence — a test passing that failed in production — I'd genuinely like to hear about it in the comments.