gotests
gotests copied to clipboard
cweill
Support custom templates with external formatters
Sometimes outputting got and want isn't enough. There are many useful OSS packages for generating pretty diffs of strings, structs, slices etc, but it would be unreasonable for this binary to require them as dependencies in the generated test files.
Instead, if the repository already has the dependency, the template will use it by automatically. This would allow users to created their own custom templates using their in-house tools.
These custom templates could be specified in a json/yaml file that define the template for a result of a given types:
For example if "github.com/tonnerre/golang-pretty" is available:
types:
- struct
- map
- slice
deps:
- github.com/tonnerre/golang-pretty
template: >
if {{.Got}} := {{Func}}({{.Args}}); !reflect.DeepEqual({{.Got}}, tt.{{.Want}}) {
t.Errorf("%v. {{Func}}() returned diff (want -> got)\n %v", tt.name, pretty.Compare(tt.{{.Want}}), {{.Got}}))
}
This will require a significant (and much needed) refactor of the render package.
The path to the templates directory should be stored in and read from an environment variable such as $GOTESTS_TEMPLATES.
@cweill I like this idea !
I thought of something similar while preparing this PR #54 : Since my IDE (GoLand) doesn't let me configure the options to pass to GoTests, I toyed with the idea of having GoTests look for a config file in the project directory to configure itself.
It could start by the folder where it was invoked, and move up until the project root, until if find a config file, e.g. .gotests.yml.
Such a file could then be used to provide custom templates to be used to generate the tests.
This approach would be more generic and flexible than a global config in $GOTESTS_TEMPLATES: I could use GoTests in a project using testify and another using the std lib for example.
If you agree with this approach, I could take a stab at preparing a PR.
@jawher: This kind of templating would be an elegant solution to most user's unique needs for how tests should look. If you have an idea of how to implement this in a generic way go ahead at take a shot. I do like the idea of having a config per project. Note, the config file should be written in a config language that doesn't require any external dependencies to parse, such as XML or JSON (I don't think there is a first-class YAML parser in the Go std lib).
There will likely be some back and forth between us about the final implementation details, but if you want to take a shot at this non-trivial feature, be my guest. :)
TOML will be added to Go std lib when https://github.com/golang/dep will be absorbed.
