Elm Regression Testing

:recycle: Elm Regression Testing :recycle:

I’m pleased to announce the release of my first Elm tool ever :smile:This is a regression test generator tool that I’ve created for a refactoring kata at the Elm Paris meetup. After some work to make it reusable, I’ve released it under an Elm package and a companion CLI tool.

Everything is described in the README, but the process can basically be described by the schema bellow:

Also, you can watch the video I’ve done showing how to use it on a refactoring kata (I hope my english is not too painfull… :sweat_smile:)

How does it differ from unit tests or fuzz tests?

Regression tests are used when you do know very little about what the code is doing, or when you’re not sure to know exactly what should happen in edge cases.

You take a footprint of your working program then use it later to compare to your refactored program.

When you do know what your program is doing, fuzz testing and unit testing are far more suited and makes more sense.


I’m happy to contribute to the Elm community and would love to have your feedback about it!

I need to say a big thanks to @jfmengels and @FBerthelot who helped me a lot during the conception of this tool!


I saw Jordane demo this at the last Elm Meetup in Paris before the Great Confinement. It was, in a word, amazing. He took an unknown and somewhat crappy code base (if I remember correctly), generated the tests, and then proceeded to fearlessly refactor the code, making it into something beautiful.

I think that this tool can be useful even for one’s own projects. Imagine a lazy developer (it could be me, for example). He didn’t writer many tests, or perhaps none at all. He comes back to his project a year after finishes it and doesn’t remember much, but wants to clean things up. This tool can help.


Is regression testing similar to snapshot testing in Jest? (Actually useful beyond testing views.)

This regression testing tool only test the logic part, it can’t test the UI, so it’s not like snapshot testing, but the philosophy is the same: take a footprint of what you’re trying to test (here the program update, for Jest the UI) and compare it afterwards with the result of your refactoring.

I think that the difference with “traditional” snapshot testing is that with snapshot testing you already have a set of tests that create the snapshots.

With this tool, it starts by generating snapshots from scratch using the inputs you generate for it, and then you refactor the tests while trying to preserve the old results.

Thanks for your kind words! I still need to complete the refactoring kata and push the solution to the Github repository :grinning:

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.