I tried this strategy when I first started with elm, but felt like my tests just reproduced the implementation in another form.
I’m not sure how Elmer solves this differently compared to elm-html-test and elm-testable. Can you give a code example of this? I’d help me understand a ton. My current understanding is that Elmer provides the exact same as elm-testable right now. Is there some other difference in the API that I missed?
Elmer is not a perfect solution. It relies on a small bit of native code. But it allows me to write tests that give me freedom to refactor my code while remaining confident that my software has all the behavior I expect.
You could’ve built this on top of elm-html-test, without requiring additional kernel code. Which is what elm-testable did :D. We added support for event-testing in elm-html-test so that elm-testable could make exactly these types of queries. I’d love to enable your project too, so if there’s something that you need to be provided by elm-html-test and elm-test, let’s talk!
However, elm-testable tightly couples code and tests in the other direction, since my code now has to use the elm-testable modules, that is the ‘testable’ version of the Http package and so on.
This is true right now! However, this has been raised as an issue previously, and the plan for elm-testable’s next avh4 version to not require this at all. This is currently on hold for the next release of Elm, as there will be related changes for elm-test to be done there. Are there any things you found in Elmer that you prefer to elm-testable? I’m super curious to hear if so.
Contributing to the community
I thought I might write up a little bit about how I feel we’ve managed in the community to increase the number of high quality libraries in the Elm community, and avoid the “framework overload” that is usually experienced in the frontend world. This is related to the talk Code is the easy part by Evan, which is worth a watch.
I believe in the community, a healthy process looks like this:
- Come up with some novel idea or new approach
- Maybe implement a proof of concept if it enables discussion
- Discuss in the community, especially if a tool already exists (Slack is the best place for this IMO)
- If it makes sense to be added to another library, great! Now there is one less library to choose from.
- If not, then it’s not and that’s okay too, and a new package is born.
What happens sometimes is that people skip 3 and 4 and go straight to 5. Which is totally fine, though it does create fragmentation which didn’t need to exist, along with duplicating a bunch of work. I’d love to encourage the community to discuss their problems with each other, before investing a bunch of effort working on them. In some cases the conversation can just be “hey! I want to do this thing. Does anything else already do this thing?”.
In this case
As it stands, “Elmer” is less likely to be adopted because of 1) the approach taken to implement it (with a bunch of unverified kernel code), which makes it hard to install or recommend, 2) elm-html-test is part of elm-test and will be merged into elm-test next released 3) elm-testable is published and easily usable, with a lot of work gone into the API.
An example of where you would’ve benefited from using elm-html-test is to handle edge cases: I can see that “Elmer” does not account for
- Lazy views
- Mapped lazy views
- Keyed views
- Lazy keyed view
However, in elm-html-test we do account for each of those edge cases. The thing is, when a library has been used a bunch then you find more edge cases. elm-html-test has been used a bunch, and so we’ve found a lot of edge cases and addressed each.
Likewise, elm-html-test is based on a pure Elm representation of the virtual-dom. This allows us to:
- create beautiful error messages
- provide a bunch of support in the elm-test runners easily
- use decoders for all the parsing of nodes.
I would argue that 3) is the most fundamental differences between Elmer and elm-html-test: in elm-html-test, we know that the virtual-dom is correctly formed, and if it’s not, we get a nice error telling us what was missing. In Elmer, you will just get a runtime error.
If we had discussed, then we could’ve helped you to leverage elm-html-test to achieve this without duplicating the work. I believe we all benefit from talking and sharing ideas!
That’s not to say there’s something wrong with making a new library: in some cases it’s needed if the approach is radically different! But in this case, I’m not sure it is radically different. Most of the differences are actually implementation details. I guess what I’m saying is: it would’ve been awesome if we had discussed this in #testing on Slack, or even in a Github issue. Don’t get me wrong: this is cool, and I can always appreciate work gone in to improving problems you see! I just think that the community can make things better, by working together.