diffx — pretty diffs for Scala case classes

Interview with Kasper Kondzielski

Diffx is an open source project which produces pretty diffs based on the product’s structure. It’s simple to use, can work out of the box and provides a straightforward way of excluding part of a product from comparison. We asked Kasper Kondzielski about diffx’s origins.

1. Could you briefly describe what does diffx do — what problem is this trying to solve?

The main purpose of diffx is to provide a readable output of a structures comparison without requiring users to write almost any additional code. Although it should work out of the box in most cases, project specific customization can also be applied. Because this task is very common in tests, the standard way of using diffx is by one of possible test framework integrations. If you want to dig deeper into the technical details you can read more in this short introduction.

2. How did you or your team come up with an idea for this project?

Like in many other cases this project was born out of frustration with the current solutions. In our tests we tend to compare a lot of objects and speaking politely the output from the scalatest library was insufficient. Most of the time I ended up copying it to some external text editor just to align expected and actual objects side by side. I was doing that to help me spot the difference. Needless to say it wasn’t a great solution. The worst part of that was when I spent way too much time trying to figure out why my lists were different despite that scalatest showed that they were empty. Later on it turned out that an empty list and a list with an empty string were visually indistinguishable.

3. Why did you decide to engage in developing this open-source project?

From the beginning we thought that this might be a great use case for magnolia which is a typeclass derivation library. I already had some experience with it through the work on tapir project. However the usage of magnolia in tapir was quite limited at that moment and I wanted to see the full potential of typeclass derivation. Also don’t forget about the frustration. I wanted to ease myself and other programmers who are facing similar problems.

4. Is there anything specific that you learned through working on this project?

Yes, absolutely, everything which connects to the concept of the typeclass, so:

typeclass derivation

implicit resolution order

exporting implicits for further customization

debugging implicits

Also because I wanted to provide a nice api for ignoring parts of a data similar to the quicklens api, I learned how quicklens works under the hood.

5. What are the future plans for the project’s development?

From the features perspective I think that most of the things are there. I don’t want this project to grow too big. Of course there still can be more integrations, like for utest or minitest. Apart from that it would be great to measure the real compilation overhead and try to decrease it. In the future, having a support for scalajs and scala native would make this project complete.

6. What would be your advice for people willing to start their adventure with OSS?