Better error message for HTML formatter problems

[aslakhellesoy]

If the html formatter doesn't have an output directory (or if the directory doesn't exist, or is a regular file) then a confusing error message is issued.

See https://groups.google.com/forum/#!topic/cukes/6O11kiH1GRs

[nfisher]

Hi Aslak,

I've started refactoring the main method to clean up the cli interface and error output. I'll push what I have so far to my fork under the branch "issue148" so you can have a look.

Cheers,
Nathan

[aslakhellesoy]

@nfisher thanks! looking forard to seeing it.

[nfisher]

@aslakhellesoy the commit above is my initial refactoring. Long-term I'm working to separate the run commands from the RuntimeSettingsRegistry but, I need to cleanly isolate everything first. If you have a moment can you give a quick peek at the commit and let me know if you're okay with the general direction before I invest more time.

[aslakhellesoy]

This looks very similar to what I have done (but not completed) in 2e18a7d (on my options-refactoring branch).

I have special reasons for wanting to make a RuntimeOptions object like that. It's so that we can populate it from a JUnit @Options annotation as well.

I like what you have done with the parsing logic inside the class itself. That means that from JUnit, we could generate an argv array from the @Options annotation - and enjoy the same error messages.

How do you feel about completing this feature? That would be awesome for all of the JUnit users out there. The full range of command line options available in Java code!

[nfisher]

Yes I have my own reasons to dump them in a registry. I'm potentially looking at writing an SWT UI runner not that I personally want it but, it would be beneficial for non-technical QA's. Could also provide some opportunities for integration with IntelliJ as a plugin when combined with a new formatter (never done one before so could be interesting).

Is there an open issue for the options annotation that I can commit against? I'll take a look at it and let you know my bandwidth once this fix is completed and merged into master.

I'm also planning to work on issue #142. Solving the issue by registering the flags with a short name and description that can be used in the help output, and the short name which could be used in control labels in a UI. Not sure where the refactoring will take me but, I was thinking it'd look something like the following;

registerFlag("--format", "-f", "Format", "for the reporting of test runs (html, pretty, etc).", OptionValues.MANY);
registerFlag("--dryrun", "-d", "Dry run", "doesn't execute any of the tests just verify the config.", OptionValues.NONE);
registerFlag("--output", "-o", "Results directory", "is where the test results are placed.", OptionsValues.ONE);

The help could then iterate over each of the strings and flags to generate its output, no need to worry about keeping the USAGE constant in sync.

[nfisher]

PS can you assign this issue to me?

[aslakhellesoy]

I have created #160.

There are many decent option parser out there. Perhaps you could use one of them? I tried JCommander at some point, and it's not bad.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.