We’ve been using elm-test for a while now and have put our tests in files in the top level tests/ directory in a hierarchy that mirrors the one in src/ but with Tests at the top.
Recently my Javascript colleagues have united around placing their units tests next to the sources files that they are testing. eg src/domain/activity.ts and src/domain/activity.test.ts.
I am curious to move in the same direction with Elm. Initially I felt that it wasn’t supported and that all tests should be in the tests/ directory, however someone suggested on slack that you could add a Tests.All modules tests/ that imported all the test files from where they live in the src/ hierarchy. I started to explore that and wrote a little basic script to auto-generate the Tests.All module. This allows you to run elm-test and for everything to still be discovered and run.
Then today, I’ve realised that you can pass files directly to elm-test like: elm-test src/**/*Test.elm in order to achieve a similar result.
My questions is: what are others doing? Have you gone one way or another? Are their particular pros & cons associated with each route? I suspect there might be issues around editor integration as you need to use elm-test make to build a test file and having the tests/ directory is one way to detect that.
I use tests/ since this is the standard for Elm related tests.
The pros to this approach is that any future alterations to the testing tools and associated integrations with editor plugins etc would be a community wide change and quite loudly advertised. The cons, at least for me, are zero.
Elm is opinionated about many things, which gives us certain restrictions of freedoms when it comes to choice. But this is precisely the point of why Elm works so well.
Your javascript colleagues have decided upon one convention, since there is no real standard practice to follow. My javascript colleagues may choose some other convention for some other equally valid set of reasons.
So, I guess my question to you would be what benefit do you see in breaking the mould (so-to-speak)? There’s no real issue in you doing it - as you say you can rig elm-test to do what you want; do you think the added hassle of maintaining a module like this to change the file layout is worth the hassle?
Good question, I should have included that It feels weird to say it but my motivation is that I’m bad at making myself write tests and so I would like to remove every possible barrier to entry. And whilst it is not a high barrier, having the test code “tucked away” in a tests/ folder rather than more “in plain sight” next to the source file is something that I would like to change to see if it helps me.
I realise it sounds super minor and therefore not worth fighting the convention over but I guess I’m looking to question the convention a little at the same time. I’m a fan of the way that Elm tries to standardise these approaches so I’m not in a hurry to advocate for everyone solving it however they’d like, but if it means I’ll write more tests then I welcome some exploration.
We are doing exactly that suggestion you mentioned. i.e. Have one Elm file in /tests that import all the tests from /src. We really like having the tests close to the code.
The drawback of this approach is that is easy to forget to include a test file in there.
But for us mirroring the app structure in /tests is more annoying than this issue.
Thanks for sharing. Interesting to see that pull request. It makes me feel like this is slightly less off the beaten track. It is for an application in my case, rather than a package.
It feels weird to say it but my motivation is that I’m bad at making myself write tests and so I would like to remove every possible barrier to entry. And whilst it is not a high barrier, having the test code “tucked away” in a