Internal Classes For HtmlReportFormatter And Others Highly Limits Reuse/Customisation

[lemonlion]

Description

I'd like to be able to make a custom HtmlReportFormatter reusing 80% of what's been done in terms of Html helper methods etc, but all the dependent classes are marked as internal.

It means if you want to even make small customisations you need to either:

• Create your own report writer from scratch, completely re-inventing the wheel for the large majority of stuff
  OR
• Copy and paste 10 internal classes from the LightBDD project
  OR
• Generate a report using the HtmlReportFormatter and then hack the html output into a final result

Am I missing something here? I understand that the downside of making classes public is breaking changes, but that can be handled with major version releases. Not allowing reuse here realistically rules out most people being able to customise reports to their needs.

There are similar (but less extensive) issues when trying to implement a custom IProgressNotifier - TextTableRenderer & TextTreeRenderer need to be copy & pasted if you want to not reinvent the wheel and the DefaultProgressNotifier doesn't have virtual methods to hook into reusability.

Progress

• Feature is implemented,
• Ensured backward-compatibility,
• Ensured good debugging experience

[Suremaker]

Hi @lemonlion ,

The logic behind report generation is currently implemented as internal classes with the reasons you have summarized above.

I do not plan to expose all of these classes out as this will limit an ability to refactor them or replace logic when necessary and it will not make the customisability any way easier.

additional reasoning

The good example is xunit which exposes tons of internal classes with virtual methods, but an attempt to customise it causes a lot of code being introduced or copied anyway. Feel free to take a look onto https://github.com/LightBDD/LightBDD/tree/master/src/LightBDD.XUnit2/Implementation/Customization to see how much had to be customised within LightBDD.

Instead of me exposing all the internals and virtualise all the private methods, could you please give some overview of the extensions you are looking to make? I will think of some extension points to be added to the library.

With LightBDD 3.7.0 and report refresh described here there is an ability to customise some parts of the reports (presented at the bottom of the linked paragraph). I will consider introducing similar extension points to the necessary sections of the report.