Some: A library to generate dummy objects for unit testing in Kotlin

We’ve all been there. You just wrote a brilliant, clean, three-line function that you want to test. You open your test file, ready to write a quick assertion, and then... you realize the function requires a User object.

The User object requires an Address. The Address requires a Country. The User also requires a list of Role objects. Suddenly, testing a simple piece of logic requires thirty lines of boilerplate code just to satisfy the compiler with dummy data.

It’s frustrating, it’s tedious, and it distracts from the actual goal: verifying your business logic. That’s exactly why I built Some, a Kotlin fixture library that help us to handle the amount of boilerplate on testing.

But before I talk about what Some does, let's talk about why testing in Kotlin needed it.

The Pain of the "Setup" Phase

When dealing with complex, deeply nested objects, manually instantiating them is a massive pain. Over the years, I've seen teams try a few different workarounds to avoid typing out endless constructor arguments, and most of them introduce even bigger problems.

To avoid writing the same massive object over and over, developers often create a shared dummyUser in a companion object or a base test class. Several tests then use this exact same instance.

This seems like a time-saver until it completely breaks test isolation. If one test mutates a shared state (or relies on a highly specific configuration of that shared object), and another test expects something else, your test suite becomes a minefield of flaky, unpredictable failures. Tests should be isolated; what happens in "Test A" should never impact "Test B".

The Fragility of Manual Instantiation

Let's say you decide to be a good citizen and instantiate fresh objects for every test. You write 50 tests for various use cases, meticulously crafting User objects for each. Then, product requirements change. You need to add a single new, non-nullable field to the User class—maybe an avatarUrl.

Suddenly, your IDE lights up with 50 compilation errors. You have to go into every single test and add avatarUrl = "http://dummy.url" just to make the project compile again. The tests breaking had nothing to do with the actual use case being tested. If the logic of the feature didn't change, why should the test need to be updated?

The Search for a Solution

I knew I needed a fixture generator—a tool that could just look at my class and give me an instance filled with random data so I didn't have to care about the fields my test wasn't actively asserting against.

For a while, I relied on existing tools like AppMattus' kotlinfixture and Kotest Arbs. I used both of them quite a bit, but I eventually hit some specific limitations with them (which I'll get into a bit later in this post). As my models got more complex, I realized nothing in the existing landscape quite fit the exact bill for what I wanted in modern Kotlin development.

That’s how Some was born. It is a Kotlin JVM library designed to do exactly one thing perfectly: generate fully populated instances of any Kotlin class with zero configuration.

Instead of this:

You just write this:

That’s it. Some handles the rest.

Why This Changes Everything

Using Some makes your tests infinitely more robust.

1. True Isolation: Every time you call some<T>(), you get a fresh, unique instance. No more sharing state across tests.
2. Resilience to Change: Remember that avatarUrl field we added earlier? If you are using some<User>(), your tests won't break when the model changes. The library simply detects the new field and generates a random string for it automatically. You only update the tests that actually care about the new field.
3. Clarity: Your tests become instantly easier to read. The setup phase is minimized, meaning whoever reads your test can focus entirely on the behavior being validated.

Under the Hood: Built for Kotlin

Because Some is written natively for Kotlin, it supports the language's best features right out of the box:

• Zero configuration: It just works. No builders or complex setup required.
• Universal Type Support: Data classes, Object singletons, Value classes, Generics, and Collections are all supported.
• Sealed Classes and Interfaces: Some seamlessly understands and resolves recursive Sealed Class and Interface hierarchies natively.
• Nested & Recursive Structures: It easily handles deeply nested data classes and circular references without getting stuck in infinite loops.
• Fine-Grained Control: While the defaults are great, you can easily override how specific fields are generated (e.g., custom string formats, specific nullable probabilities, or custom factories).

What About Existing Alternatives?

Before building Some, I explored and used other tools in the ecosystem, but they had limitations that ultimately led me to create my own.

AppMattus' kotlinfixture

I used to heavily rely on appmattus/kotlinfixture. However, it seems to have stopped receiving updates. More importantly, it uses JFixture under the hood. Because it relies on a Java library at its core, it isn't always reliable when generating fixtures related to Kotlin-specific features—like Sealed Interfaces, for example. I wanted a library that was 100% Kotlin from the ground up, built to understand Kotlin paradigms natively.

Kotest Property-Based Testing (Arbs)

Another alternative is Kotest's Property-Based Testing utilizing Arb generators. It absolutely works, but it isn’t as configurable as Some when it comes to standard fixture generation. For example, using Kotest Arbs, we can't easily control global nullability rules or dictate specific generation strategies across an entire object tree. We simply don't have the same level of granular, overarching configuration that Some provides out of the box.

Give 'Some' a Try

I originally built Some just to make my own daily testing less of a chore. But after seeing how much time it saved me, and how much cleaner my test files looked without hundreds of lines of dummy data cluttering them up, I figured it could probably help other Kotlin developers who are feeling the exact same pain.

If you’re tired of playing a never-ending game of "fill in the constructor" every time you want to verify a simple piece of logic, I'd love for you to drop it into one of your projects and see how it feels. 

Read the Documentation & Quick Start

Some - Some

A Kotlin test data generation library that creates random instances of any Kotlin class

SomeAppOutlet, Lda

Visit the GitHub Repository

I'm actively maintaining and improving it, so I'd genuinely love to hear your feedback on how it handles your specific use cases.