In this section we will look at two files:
- The example module file we will want to analyze
- The example Analyzer extension
# ./02-example-module.ex
defmodule Example do
def hello(name) do
"Hello, #{name}!"
end
end
Here we have a basic module that defines a single function Example.hello/1
. If you are familiar with exercism practice exercises, this resembles the two-fer
exercise.
An analyzer does not replace module unit tests, the goal of our analyzer is to tease out anti-patterns in passing solutions. Using this pattern detection, the goal is to provide clear, direct coaching to a student to correct the design choice.
defmodule ElixirAnalyzer.ExerciseTest.Example do # 1
use ElixirAnalyzer.ExerciseTest # 2
end
This is the bare minimum of required code for an analyzer extension. There are a few things here to look at in more detail. Looking at line 1, we can see the naming convention used by the analyzer. An analyzer extension must be named ElixirAnalyzer.ExerciseTest.__________
where the blank is the name of the module you want to analyze. In our case we can see in the code example, the name for our extension is ElixirAnalyzer.ExerciseTest.Example
.
Line 2 allows the use of the macros found in ElixirAnalyzer.ExerciseTest
, specifically the feature/1
macro. This macro will allow us to specify tests and patterns that we want to identify in the solution being analyzed.
The extension module should then be placed into the lib/
folder of the mix project, ideally in lib/elixir_analyzer/test_suite/
folder for convention.
Then we can run the elixir analyzer:
> mix escript.build
Compiling 2 files (.ex)
Generated escript elixir_analyzer with MIX_ENV=dev
> ./elixir_analyzer example-slug path/to/example/folder path/to/output
undefined analysis ... Completed!
Analysis ... Analysis Complete
Output written to ... path/to/output/analysis.json
We can then find analysis.json
at the path specified with the contents:
{"comments": [],"summary":"Submission analyzed. No automated suggestions found."}
Next steps: adding a feature test