RSpec incremental summarized output

[danielwaterworth]

I'm one of the developers working on Discourse and we have recently starting using parallel_tests. I've been tasked with making parallel rspec work more like regular rspec. We'd like to see progress as it happens and then see a single summary at the end (much like as is described in #411).

The way I've chosen to go about doing this is to make each subprocess use a custom rspec formatter that produces a json object for each event (code). The main process then parses these events and does its own reporting (code). See this PR on discourse for more information.

This will work for us, but judging by some of the issues in this tracker (#411, #523, #704), there are other users of this gem that might also benefit from such changes. However, it's quite a substantial departure from the current behavior.

Would you be interested in receiving PRs that add this functionality?

[grosser]

I like the current simplicity of "run these commands and display their output", that seems very sturdy and won't break between different frameworks and their versions.

Having an opt-in formatter that produce a more standardized output (that can later be expanded to all test frameworks) and a parser for that seems like a good enhancement though.

The common format already exists with junit output https://github.com/sj26/rspec_junit_formatter + https://github.com/aespinosa/minitest-junit + https://github.com/cucumber/cucumber-ruby/blob/master/lib/cucumber/formatter/junit.rb so ideally reuse that / instruct users what gems to add and add --junit flag to parse the the resulting files (might have to add the --format or so flags since we need to set known output locations, not sure).

[danielwaterworth]

It looks like we're in slightly different positions here:

Discourse uses one version of one testing framework and we decide when to upgrade it, but parallel_tests supports many versions of many testing frameworks and can't anticipate new versions.

In light of that, I definitely see the benefit of a common test suite format. Any summarizing and displaying becomes test-suite independent and it reduces the amount of test-framework specific code compared to my approach.

However, for our purposes, junit xml is less than ideal because it's not incremental, but it looks like TAP-Y/J might work. There's https://github.com/rubyworks/rspec-ontap and https://github.com/rubyworks/minitap, but cucumber is missing.

[grosser]

Oh yeah that looks interesting! :)

…

On Thu, Jun 20, 2019 at 2:35 AM Daniel Waterworth ***@***.***> wrote: It looks like we're in slightly different positions here: Discourse uses one version of one testing framework and we decide when to upgrade it, but parallel_tests supports many versions of many testing frameworks and can't anticipate new versions. In light of that, I definitely see the benefit of a common test suite format. Any summarizing and displaying becomes test-suite independent and it reduces the amount of test-framework specific code compared to my approach. However, for our purposes, junit xml is less than ideal because it's not incremental, but it looks like TAP-Y/J <https://github.com/rubyworks/tapout/wiki/TAP-Y-J-Specification> might work. There's https://github.com/rubyworks/rspec-ontap and https://github.com/rubyworks/minitap, but cucumber is missing. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#708?email_source=notifications&email_token=AAACYZ2IKIGZMVB76RKNDVDP3NFPBA5CNFSM4HZIIE22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYE34WA#issuecomment-503955032>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAACYZ5LLZWA2QCU37DRCGLP3NFPBANCNFSM4HZIIE2Q> .

[danmayer]

I would be really interested if this gets rolled into parallel_tests, very cool work