Testing code generators can be tricky, but very rewarding as it makes developing CodeGenerators much easier.
Like codeGenTest, but expects the code generator to not be able to generate code. The final string is the expected error message.
Like codeGenTest, but runs in incremental mode. Only looks for a fix for the first Debug.todo found.
Creates a fake elm review dependency type. This should only be used with the other helpers in this module, as the information inside the returned type is mostly rubbish.
How do you get this value without too much pain? I usually go to package.elm-lang.or, find the package I'm interested in, open the dev tools, in the Network tab find the docs.json,
select Preview, right-click and "Store as global variable", then run the following snippet:
copy(
`fakeDependency \n { name = ${JSON.stringify(
window.location.pathname.split("/").slice(2, 4).join("/")
)}\n , dependencies = []\n , modules =\n [ ${temp1
.map(
(mod) =>
`{ name = ${JSON.stringify(mod.name)}\n , values =\n [ ${mod.values
.map((v) => `( ${JSON.stringify(v.name)}, ${JSON.stringify(v.type)})`)
.join("\n , ")}\n ]\n }`
)
.join("\n , ")}\n ]\n}`
);Represents a dependency that the user has in their project.
Tests that a single
Debug.todogets replaced with a particular piece of code.The arguments are:
Description (i.e. what you would normally pass to
Test.test)A list of dependencies. Note that this rule will only activate code generators based on dependencies in the user's project. This allows you to control which dependencies are present.
A list of code generators. Typically this will be the code generator under test, but can also be used to test interactions between multiple.
A list of code modules that form the project the rule is being run on. Exactly one of these must have a single top level
Debug.todothat the test is trying to replace.The expected source code of the module containing the
Debug.todoafter running the code generator.