Spec::JUnitFormatter: Allow output directory as --junit_output

[bcardiff]

Follow up of #8599 (comment)

[RX14]

Why not just append output.xml to your configuration? I really don't get why hardcoding output.xml has any benefit at all here.

Until there's actually any way, or need, to generate multiple files, I'd prefer it stay as it is.

[bcardiff]

Because it keeps compatible with the previous behaviour without ambiguity.
And leave space for future improvements.
Allowing --junit_output ./test_results/foo.xml should have not invalidate --junit_output ./test_results

[RX14]

Nobody has explained why splitting the results would be an improvement, and we've already made the breaking change in a release. I see no benefit to previous behaviour at this point.

[bcardiff]

This is preventing the breaking change on master. There was no tagged release with that behavior.

I mentioned here some scenarios for splitting #8599 (comment) .

[RX14]

Right, sorry, I thought that'd made it into a release somehow.

[Sija]

That belongs to src/spec.cr, not here.

crystal/src/spec.cr

Lines 132 to 135 in 42a6490

	opts.on("--junit_output OUTPUT_PATH", "generate JUnit XML output within the given OUTPUT_PATH") do |output_path|
	junit_formatter = Spec::JUnitFormatter.file(Path.new(output_path))
	Spec.add_formatter(junit_formatter)
	end

[bcardiff]

I don't agree. It depends on the semantics of the argument.

One could say that the creation of the parent directory also belongs to the CLI.

The .file methods acts as a helper, the real deal is the initialize(IO).

[Sija]

IMHO .file is expecting a path to... the file - not some arbitrary path to mutate afterwards - the whole logic of "tweaking" the path should be done outside - in this case by spec itself.

[bcardiff]

For me is a path configuration of the output formatter. If there is splitting how to split and which file to create would belong in the formatter and not spec itself since it is not something shared with other formatters like DotFormatter.

[Sija]

[...] since it is not something shared with other formatters like DotFormatter.

That's exactly my point, formatter itself shouldn't be responsible for doing any magic with the given path. If I'm calling Spec::JUnitFormatter.file(path) I'd expect to pass a file path to it...

[RX14]

I don't like it, but it's restoring previous behaviour so

[straight-shoota]

@RX14 I agree, it's not ideal solution. At some point we need to figure out if writing to different files is actually going to happen and we can reconsider and if necessary break things then.

[RX14]

I'd prefer to rule out ever doing that sooner rather than later, as a form of YAGNI simplification.

Another option can always be added in the (unlikely) case anyone ever fleshes out some rules to generate multiple XML documents. I think most people are just going to have multiple top-level spec suite files if they want to do this. And I don't think they ever will actually want to do this.