Custom results output

[jcline]

From the readme:

A standard output format that can be used with available visualizers would be very useful.

Right now I have a janky local modification we're using to integrate with http://phabricator.org/, but it would be nice to refactor this into something less hacky.

I was thinking something like this would work:

public enum CoverageType {
  Hit,
  Miss
}

public struct Result {
  public int startLine;
  public int endLine;
  public string path;
  public CoverageType coverage;
}

public interface IResults {
  void Write(IList<Result> results);
}

Then users can add their own IResults and it would be simple to add a configuration option to coverage.json.

If this seems reasonable to you then I'd be happy to write it and put up a pull request?

[yonderblue]

So are you suggesting the output be in actual C#, or serialized C#? In the readme I was hoping there might be some tools out there that can highlight source lines and perhaps this tool could generate its output in their format, but I am not seeing a lot out there. So perhaps just html output that is decent looking that highlights the lines would be useful here. How would you use the format you put above?

[jcline]

I'm suggesting providing an interface so that people can provide their own deserialization classes without having to hack Check(). There may be a more idiomatic way of doing this, but I've been writing a lot of Go recently so this is what came to mind.

tools out there that can highlight source lines and perhaps this tool could generate its output in their format

The hack I have in place now outputs in a format compatible with Phabricator, which shows the coverage inline with code posted for review. The format is described at http://www.phabricator.com/docs/phabricator/article/Arcanist_User_Guide_Code_Coverage.html#building-coverage-suppor

Additionally, I'd assume you'd want to encourage people who wrote deserializers to contribute them back to this project (I was planning on doing so, at least).

[yonderblue]

ok in that case to keep the actual output fast while the tests are running the existing format should be kept, and another subcommand added to the tool that allows the output translated to another format from the existing one. Then users could feed those back into the project like you suggest. Sound good, or am I unclear?

[jcline]

That sounds perfect for what we would need.

[yonderblue]

Hey if you have a sec check out the view branch and let me know what you think!

Let me know if that would serve your purposes of easily adding another custom view, similar to how the basic one is in there.