Follow up #1670: Fix StyleCop issues and improve the code#1711
Follow up #1670: Fix StyleCop issues and improve the code#1711
Conversation
|
@ggnaegi FYI |
|
@RaynaldM Hey, Ray! |
@raman-m I could review it...Because most of it is not my code. |
|
@ggnaegi Your approval will have gray status which means it does not approve the PR actually and uncover PR status to merge. |
9f560b0 to
44d5a5a
Compare
44d5a5a to
b905fde
Compare
|
@ggnaegi Will you review? |
There was a problem hiding this comment.
@raman-m I reviewed the code:
-
- ServiceValidationWarningFormat -> I would use a static factory method, otherwise it's error prone
-
- ThenTheLoggerHasBeenCalledCorrectlyWithValidationWarning -> I would implement only one theory instead of 3 facts, otherwise we would have to verify the port or url explicitely to match the fact name
-
- My bad, The theory and facts names are wrong -> should_return_provider_according_to_service_name
| .When(x => WhenIGetTheServices()) | ||
| .Then(x => ThenTheCountIs(0)) | ||
| .And(x => ThenTheLoggerHasBeenCalledCorrectlyForInvalidPorts()) | ||
| .And(x => ThenTheLoggerHasBeenCalledCorrectlyWithValidationWarning(serviceEntryOne, serviceEntryTwo)) |
There was a problem hiding this comment.
We could go a step further here and implement a theory instead of 3 facts, otherwise I would expect an explicit port or url validation.
There was a problem hiding this comment.
A-ha-ha! It seems I found the bug made by Tom in 11a2d13 on line 61...
If address contains http OR address contains https then it is actually valid but it returns false 🤣
SO, assumption in the should_not_return_services_with_invalid_address test is wrong because Address = "http://localhost" is valid, but the test considers it as invalid because of the bug in boolean formula of the predicate. 🥸
Okay... Tom... Good job! 🤣
Update 1
Sorry, my bad!
localhost is valid, but if scheme in a string like http://localhost then it is invalid. This is the requirement of Consul AgentService class. So, not an issue. The test is correct.
So, I was confused by Address, for AgentService it is host actually.
There was a problem hiding this comment.
@ggnaegi Partially fixed in 5851300
Regarding Theory... You will be able to refactor these 3 tests as you wish in the next PRs... 😉
Currently I cannot merge 3 tests to one theory because of closure of _serviceName private member while AgentService creating, but MemberData attribute of Theory requires only static property/member and it has no access to object members! So, it will be a little challenge for you. 😄
And version you've reviewed just a refactoring, I test the same for which these tests were written. So, port & service name checking is encapsulated inside of the warning expected string.
So, writing something like actualWarning.ShouldContain(portString) will be overhead checks.
Finally, I believe, it is not an issue.
|
|
||
| [Fact] | ||
| public void should_return_SameProviderForGivenServiceName() | ||
| public void ShouldReturnSameProviderForGivenServiceName() |
There was a problem hiding this comment.
I think here it should be should_return_same_provider_for_given_service_name, it matches the naming conventions.
There was a problem hiding this comment.
Hmm... BDDfy can work with different name conventions: "You can use underscored or pascal or camel cased method names for your steps"
But the C# naming convention is PascalCase. As for C# developer, as for me, it is very strange to see C & C++ naming convention with _ (underscores) in method names!
In future I am going to fix this huge problem.
2nd problem. Visual Studio generates a lot of IDE1006 Naming rule violation because method name is not PascalCase.
But for now, it seems scenarios with PascalCase is not logged into build log at all. Probably it is Ok because passed scenario should not be logged by default.
Currently all BDDfy unit tests are logged producing huge logs... But this is another story.
It makes a lot of sense to change names from underscore-style (C++) to C# PascalCase because of the following:
- Passed unit test will not be logged by BDDfy framework to build console on CircleCI
- Method names of unit tests don't violate default C# naming conventions (aka IDE1006 rule, etc.)
There was a problem hiding this comment.
@raman-m Ok, Raman it makes sense: So, we could keep it like that and create a new PR for theories / facts naming conventions. I'm not used to the underscore naming convention either.
There was a problem hiding this comment.
It makes too much sense... But not in this PR which I would like to merge today :)
It will another huge PR to resolve mentioned problems... in October from me... 😸
It seems I must create another follow up issue after this follow up... 🤣 I'm going crazy with this project...
|
@RaynaldM Sorry, there will be a number of code review commits... Wait for my next message please! |
Create expected value from a hardcoded string in unit tests
|
@ggnaegi I've resolved issues of your code review! |
|
@RaynaldM I'm sorry that I dismissed your approvals multiple times! |
|
4 ⭐⭐⭐⭐ to Raman Maksimchuk 🥇 Honoring 🏅 aka Top Contributors 👏1st 🥇 goes to Raman Maksimchuk for delivering 4 commits Starring ⭐ aka Release Influencers
|
September 2023 (version 19.1.0)Honoring 🏅 aka Top Contributors 👏1st 🥇 goes to raman-m for delivering 7 features Starring ⭐ aka Release Influencers
|
Relates to #1670
This is follow up PR after merging of PR #1670
Proposed Changes