Test your review using elm-explorations/test.
Implementing a review works really well in a Test-Driven loop:
foo, write a test
that ensures that the use of variables named differently does not get reportedDebug.todo etc to cut corner casesThen repeat for every case that needs to be handled. Ideally, by only reading through the test titles, someone else should be able to recreate the rule you are testing.
Tests are cheap and it is better to have too many tests rather than too few, since the behavior of a review rarely changes drastically.
If you like putting Debug.logs in your code as much as I do,
run your tests with elm-test-rs.
The default project after elm init minus the elm/html and elm/browser dependencies.
Equivalent to (copy and adapt if necessary)
{ elmJson = """
{
"type": "application",
"source-directories": [
"src"
],
"elm-version": "0.19.1",
"dependencies": {
"direct": {
"elm/core": "1.0.5"
},
"indirect": {
"elm/json": "1.1.3"
}
},
"test-dependencies": {
"direct": {},
"indirect": {}
}
}
"""
, directDependencies = []
}(elm/core is automatically part of every tested project)
An expectation for the reported error range.
If the section to mark is unique in the source, use Under "your section source".
If the section occurs multiple times in the source, use UnderExactly { section = "your section source", startingAt = { row = ..., column = ... } }
Run a
Reviewon a project, matching all reported module errors,elm.jsonerrors and extra file errors with your provided expected errors.The extra indentation specified by the first line will be stripped of all the provided source strings.
You can also specify a custom project config in case you need to test a package or want to add dependencies (elm/core is automatically part of every tested project) by supplying the raw sources for the
elm.jsonand the direct dependencydocs.jsonandelm.jsonyou can find in your elm root folder.