Support registering multiple handlers in the same class

[wassim-k]

Fixes #40

I've created unit tests to replicate the issue and they all pass including integration tests.

[wassim-k]

This change is not related to the fix, but I thought we can avoid constructing the handler types array multiple times.

[codecov]

Codecov Report

❌ Patch coverage is 99.19355% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/DispatchR/Configuration/ServiceRegistrator.cs	99.10%	0 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[wassim-k]

@hasanxdev Can you please provide more info on where I should be placing the tests?
I can't see NotificationHandlerTests under UnitTests
Also should I define MultiNotificationHandler, MultiRequestHandler, TestNotification1...3 and TestRequest1...3 all in TestCommon? or keep them encapsulated within the unit test?

[hasanxdev]

@wassim-k Please place the main test that includes the Fact for notifications in this file:
NotificationTests.cs

For the handlers, put them inside this file:
RequestHandlerTests.cs

If you need to create a new file, please move it into the DispatchR.TestCommon.
That applies to your files MultipleInterfacesTests and MultiRequestHandler:
PR Link

[wassim-k]

Tests are updated, and I can confirm 100% coverage of code changed in this PR.

[wassim-k]

Hi @hasanxdev, codecov seems to also take testing code into account, should that be excluded from the report?

[hasanxdev]

Hi @wassim-k ,
Please see if you can somehow resolve this issue, either by covering it with tests or by adjusting the way the tests are written.

Since this library is still quite new, it’s already hard for people to trust it. A 100% test coverage isn’t necessarily what makes developers adopt a library, but it’s definitely one of the key factors they consider.

If we don’t address this, all the effort we’ve put into building this library might get overlooked, because no one has the time to dig into what exactly isn’t covered, they’ll just see that the test coverage is low.

Thank you so much, and I apologize for the delayed response.

[wassim-k]

I understand, but code coverage is for library code not test code, can you configure it to exclude test projects/directory?
Otherwise, it might degrade the quality of the tests themselves when we have to, for example, invoke handlers unnecessary just to hit the code coverage.
Or is there a reason you want test code to also be 100% covered?

[hasanxdev]

Looks good bro, I’m doing the final review of your code.
99% coverage is awesome! If everything checks out, I’ll go ahead and merge it.

[hasanxdev]

Thank you for helping in the development of this library.