# Elm Backwards Compatability Tester
**URL:** https://discourse.elm-lang.org/t/elm-backwards-compatability-tester/9650
**Category:** Show and Tell
**Created:** [February 10, 2024, 9:21pm UTC](https://discourse.elm-lang.org/t/elm-backwards-compatability-tester/9650 "2024-02-10T21:21:42Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@Magnetize2072](https://discourse.elm-lang.org/u/Magnetize2072)
#### Post date: [February 10, 2024, 9:21pm UTC](https://discourse.elm-lang.org/t/elm-backwards-compatability-tester/9650/1 "2024-02-10T21:21:42Z")
Here’s a small tool I wrote so you can test backwards compatability.
> **[GitHub - matt-savvy/elm-backwards: Elm Backwards Compatability Tester](https://github.com/matt-savvy/elm-backwards)**
>
> Elm Backwards Compatability Tester. Contribute to matt-savvy/elm-backwards development by creating an account on GitHub.
Test your currently checked out code against the tests for any previous versions. Use when publishing a new minor or patch version of your package to make sure you’re not making a breaking change.
[](https://asciinema.org/a/637454)
This is an idea I’ve had in the back of my head for a long time. I don’t even publish packages, but I just wanted to make it. Hope this is helpful (or at least interesting) for package authors!
[Doesn’t Elm packages already enforce Semver?](https://github.com/matt-savvy/elm-backwards?tab=readme-ov-file#doesnt-elm-packages-enforce-semver)
Related thread: [Semver enforcement](https://discourse.elm-lang.org/t/semver-enforcement/9263)
---
### Author:  [@jfmengels](https://discourse.elm-lang.org/u/jfmengels)
#### Post date: [February 10, 2024, 11:19pm UTC](https://discourse.elm-lang.org/t/elm-backwards-compatability-tester/9650/2 "2024-02-10T23:19:43Z")
This is pretty interesting. I’m curious what use-cases you were trying to have this find though.
The one that comes to mind is to figure out in which version a bug was introduced, but that’s kind of the backwards approach (test previous versions’ code with the current tests, after introducing a new test)
> Use when publishing a new minor or patch version of your package to make sure you’re not making a breaking change.
Usually, tests are the standard to determine whether something is correct. Testing with old versions’ tests is only useful if tests were over time either removed or modified. But tests are usually modified either to make the test more complete, or to reflect a behavior change (often for bug fixes).
I’m curious what your thoughts are.
---
### Author:  [@Magnetize2072](https://discourse.elm-lang.org/u/Magnetize2072)
#### Post date: [February 11, 2024, 6:11pm UTC](https://discourse.elm-lang.org/t/elm-backwards-compatability-tester/9650/3 "2024-02-11T18:11:16Z")
> Testing with old versions’ tests is only useful if tests were over time either removed or modified. But tests are usually modified either to make the test more complete, or to reflect a behavior change (often for bug fixes).
Pretty much this kind of thing. _Usually_ tests are being updated so that the next version’s tests are a superset of the previous version’s, but there’s nothing to guarantee that. The two main examples that I can think of are when tests are refactored or public code behavior gets changed.
1. Tests have been refactorted: let’s say v1.0.0 is stable, v1.1.0 refactors the tests that unintentionally leave a code path untested. v1.2.0 introduces a bug in this code path and the author isn’t aware they’ve broken backwards compatibility because the tests all pass. But if you run this version’s code against the tests from v1.0.0, you’ll catch it.
2. Public code gets changed: I wouldn’t worry too much about bug fixes, since a previous version probably doesn’t have a test that asserts on this buggy output. But there’s nothing stopping someone from changing their tests at the same they change some behavior. For example, some function `f : Int -> Int` that previously operated on all inputs now handles negative numbers differently.
If this testing strategy were enforced for all packages, everyone would just have that much more peace of mind when it comes to bumping minor and patch versions.
All that being said, this is probably more of an argument for everyone to have good test coverage for their own code - if a minor/patch version bump changes in a way that affects your code, you ideally will catch it pretty quickly.
> The one that comes to mind is to figure out in which version a bug was introduced, but that’s kind of the backwards approach (test previous versions’ code with the current tests, after introducing a new test)
Yeah, exactly, this tool won’t help you at all here. (a clever `git rebase` and `git bisect --run ` can already automate this though)
---
### Author:  [@rupert](https://discourse.elm-lang.org/u/rupert)
#### Post date: [February 12, 2024, 10:39am UTC](https://discourse.elm-lang.org/t/elm-backwards-compatability-tester/9650/4 "2024-02-12T10:39:35Z")
Strikes me that it could also be useful for package maintainers.
When publishing a new minor or patch version, could compare test results with the previous version to compare. It might help to check you haven’t made a mistake, and could also help when writing the documentation, if it flags up some things that you really ought to mention in the release notes.
---
### Author:  [@Magnetize2072](https://discourse.elm-lang.org/u/Magnetize2072)
#### Post date: [February 12, 2024, 2:16pm UTC](https://discourse.elm-lang.org/t/elm-backwards-compatability-tester/9650/5 "2024-02-12T14:16:07Z")
> Strikes me that it could also be useful for package maintainers.
>
> When publishing a new minor or patch version, could compare test results with the previous version to compare
Yup, that’s exactly who I had in mind.
---
### Author:  [@system](https://discourse.elm-lang.org/u/system)
#### Post date: [February 22, 2024, 2:16pm UTC](https://discourse.elm-lang.org/t/elm-backwards-compatability-tester/9650/6 "2024-02-22T14:16:34Z")
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.