[Core] The SummaryPrinter should only depend on api classes

[brasmusson]

Summary

The SummaryPrinter interface should only depend on api classes

Details

A plugin interface like the SummaryPrinter, which users can implement, should only depend on classes in cucumber.api packages.

Motivation and Context

API classes should not leak internal interfaces.

How Has This Been Tested?

Tested by the automated test suite.

Types of changes

• Bug fix (non-breaking change which fixes an issue).
• New feature (non-breaking change which adds functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as expected).

Checklist:

• I've added tests for my code.
• My change requires a change to the documentation.
• I have updated the javadoc documentation accordingly.

[coveralls]

Coverage decreased (-0.008%) to 80.296% when pulling 7be8c2d on summary-printer-interface into 4d09d8c on master.

[mpkorstanje]

I am thinking we should remove the SummaryPrintingInterface from the public API all together. Given the current interface there are two reasonable implementations and we're providing them both.

Custom implementations can listen to the the event stream like the other plugins.

[mpkorstanje]

Maybe we can combine the whole thing with Stats? And trigger the printing when the TestRunFinished event comes by.

[mpkorstanje]

Okay. Removing the summary printer from the public API was a bit too much. But I've managed to pull stats and UndefinedStepsTracker out of the runtime. It gets a bit messy around Android and PaxExam but that is okay I think.

[brasmusson]

I can think of another reasonable implementation for the SummaryPrinter interface, that is to only print the snippets. When a runner class is used the NullFormatter is the default formatter for the console. One could argue that when using a runner class maven/gradle/testng should take care of the test summary and test errors, so the only thing Cucumber-JVM should provide is the snippets.

That leads to the question which helpers Cucumber-JVM should provide to simplify the development of different types of plugins, like classes as Stats, UndefinedStepsTracker, TestSourceModel etc.

[mpkorstanje]

I've been having similar thoughts.

The summary plug is really suited to the commandline runner. All the other runners have their own reporting mechanism. However the ports and adapters pattern we're using makes the commandline runner (through runtime options) the nucleus for all adapters. It should be the Runtime that is the nucleus.

It's why I had to add noSummaryPrinter to get rid of the default.

[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.