Internal Classes For HtmlReportFormatter And Others Highly Limits Reuse/Customisation about lightbdd

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