Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Follow up #1670: Fix StyleCop issues and improve the code #1711

Merged
merged 11 commits into from
Oct 2, 2023

Conversation

raman-m
Copy link
Member

@raman-m raman-m commented Sep 30, 2023

Relates to #1670

This is follow up PR after merging of PR #1670

Proposed Changes

  • Reviewed the code of the related PR
  • Removed code smells
  • Fixed StyleCop rules violations
  • Made code improvements

@raman-m raman-m requested a review from RaynaldM September 30, 2023 12:23
@raman-m
Copy link
Member Author

raman-m commented Sep 30, 2023

@ggnaegi FYI
As we agreed on PR 1670 merging I've created this PR.

@raman-m
Copy link
Member Author

raman-m commented Sep 30, 2023

@RaynaldM Hey, Ray!
I will appreciate your review and approval ASAP.
Thank you!

@raman-m raman-m self-assigned this Sep 30, 2023
@raman-m raman-m added good first issue Should be pretty easy to do proposal Proposal for a new functionality in Ocelot Service Discovery Ocelot feature: Service Discovery labels Sep 30, 2023
@ggnaegi
Copy link
Member

ggnaegi commented Sep 30, 2023

@ggnaegi FYI
As we agreed on PR 1670 merging I've created this PR.

@raman-m I could review it...Because most of it is not my code.

@raman-m raman-m changed the title Follow up #1670: Remove code smells and improve the code Follow up #1670: Fix StyleCop issues and improve the code Sep 30, 2023
@raman-m
Copy link
Member Author

raman-m commented Sep 30, 2023

@ggnaegi Your approval will have gray status which means it does not approve the PR actually and uncover PR status to merge.
But your opinion is welcomed! I could even fix something if you judge my code 😉

@raman-m raman-m force-pushed the bug-1634-followup-of-PR-1670 branch from 9f560b0 to 44d5a5a Compare September 30, 2023 14:33
@raman-m raman-m force-pushed the bug-1634-followup-of-PR-1670 branch from 44d5a5a to b905fde Compare September 30, 2023 14:48
@raman-m
Copy link
Member Author

raman-m commented Oct 1, 2023

@ggnaegi Will you review?
Is it Okay to merge?

@ggnaegi
Copy link
Member

ggnaegi commented Oct 1, 2023

@ggnaegi Will you review?

@raman, yes sure, probably in the afternoon...

Copy link
Member

@ggnaegi ggnaegi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@raman-m I reviewed the code:

    1. ServiceValidationWarningFormat -> I would use a static factory method, otherwise it's error prone
    1. 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
    1. My bad, The theory and facts names are wrong -> should_return_provider_according_to_service_name

src/Ocelot.Provider.Consul/ConsulRegistryConfiguration.cs Outdated Show resolved Hide resolved
src/Ocelot.Provider.Eureka/EurekaProviderFactory.cs Outdated Show resolved Hide resolved
@@ -193,47 +193,18 @@ public void should_not_return_services_with_invalid_port()
.And(x => GivenTheServicesAreRegisteredWithConsul(serviceEntryOne, serviceEntryTwo))
.When(x => WhenIGetTheServices())
.Then(x => ThenTheCountIs(0))
.And(x => ThenTheLoggerHasBeenCalledCorrectlyForInvalidPorts())
.And(x => ThenTheLoggerHasBeenCalledCorrectlyWithValidationWarning(serviceEntryOne, serviceEntryTwo))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@raman-m raman-m Oct 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@raman-m raman-m Oct 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@raman-m Ok 😄

{
var provider = DummyPollingConsulServiceFactory(string.Empty);
var pollProvider = provider as PollConsul;
pollProvider.ShouldNotBeNull();
}

[Fact]
public void should_return_SameProviderForGivenServiceName()
public void ShouldReturnSameProviderForGivenServiceName()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think here it should be should_return_same_provider_for_given_service_name, it matches the naming conventions.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

@ggnaegi ggnaegi Oct 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✔️ Fixed in 842a941

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

test/Ocelot.UnitTests/Consul/ProviderFactoryTests.cs Outdated Show resolved Hide resolved
test/Ocelot.UnitTests/Consul/ProviderFactoryTests.cs Outdated Show resolved Hide resolved
src/Ocelot.Provider.Consul/Consul.cs Outdated Show resolved Hide resolved
RaynaldM
RaynaldM previously approved these changes Oct 2, 2023
RaynaldM
RaynaldM previously approved these changes Oct 2, 2023
@raman-m
Copy link
Member Author

raman-m commented Oct 2, 2023

@RaynaldM Sorry, there will be a number of code review commits... Wait for my next message please!

RaynaldM
RaynaldM previously approved these changes Oct 2, 2023
@raman-m raman-m requested a review from ggnaegi October 2, 2023 13:59
@raman-m
Copy link
Member Author

raman-m commented Oct 2, 2023

@ggnaegi I've resolved issues of your code review!
Are we done?

@raman-m raman-m requested a review from RaynaldM October 2, 2023 14:01
@raman-m
Copy link
Member Author

raman-m commented Oct 2, 2023

@RaynaldM I'm sorry that I dismissed your approvals multiple times!
Make a final approval, plz 🙏

Copy link
Member

@ggnaegi ggnaegi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes!

@raman-m raman-m merged commit e5f31ef into develop Oct 2, 2023
@raman-m raman-m deleted the bug-1634-followup-of-PR-1670 branch October 2, 2023 16:18
@raman-m raman-m added accepted Bug or feature would be accepted as a PR or is being worked on and removed good first issue Should be pretty easy to do labels Oct 2, 2023
@raman-m
Copy link
Member Author

raman-m commented Oct 4, 2023

4 ⭐⭐⭐⭐ to Raman Maksimchuk 🥇
3 ⭐⭐⭐ to jlukawska 🥈
2 ⭐⭐ to Guillaume Gnaegi 🥉


Honoring 🏅 aka Top Contributors 👏

1st 🥇 goes to Raman Maksimchuk for delivering 4 commits
2nd 🥈 goes to jlukawska for delivering 3 commits
3rd 🥉 goes to Guillaume Gnaegi for delivering 2 commits in 2 files changed
3rd 🥉 goes to Ben Bartholomew for delivering 1 feature in 3 files changed with 83 insertions
3rd 🥉 goes to Guillaume Gnaegi for delivering 1 feature in 3 files changed with 13 insertions and with 422 deletions

Starring ⭐ aka Release Influencers :bowtie:

⭐⭐⭐⭐ Raman Maksimchuk
⭐⭐⭐ jlukawska
⭐⭐ Guillaume Gnaegi
⭐ Anthony Steele
⭐ Ben Bartholomew
⭐ DanHarltey
⭐ Fabrizio Mancin
⭐ Freddy
⭐ Kevin Grossmann
⭐ Marco, Roman, Thiago Loureiro, Vijay Karavadra, guoyongchang, leonluc-dev, raman-m, zhangq


1st 🥇 goes to DanHarltey for delivering 1 feature in 8 files changed
2nd 🥈 goes to Ben Bartholomew for delivering 1 feature in 3 files changed with 83 insertions
3rd 🥉 goes to Guillaume Gnaegi for delivering 1 feature in 3 files changed with 13 insertions and 422 deletions

@raman-m
Copy link
Member Author

raman-m commented Oct 5, 2023

September 2023 (version 19.1.0)

Honoring 🏅 aka Top Contributors 👏

1st 🥇 goes to raman-m for delivering 7 features
2nd 🥈 goes to Raman Maksimchuk for delivering 4 features
3rd 🥉 goes to jlukawska for delivering 3 features

Starring ⭐ aka Release Influencers :bowtie:

⭐⭐⭐⭐⭐⭐⭐ raman-m
⭐⭐⭐⭐ Raman Maksimchuk
⭐⭐⭐ jlukawska
⭐⭐ Guillaume Gnaegi
⭐ Anthony Steele
⭐ Ben Bartholomew
⭐ DanHarltey
⭐ Fabrizio Mancin
⭐ Freddy
⭐ Kevin Grossmann
⭐ Marco
⭐ Roman
⭐ Thiago Loureiro
⭐ Vijay Karavadra
⭐ guoyongchang
⭐ leonluc-dev
⭐ zhangq

Features in the Release

deleted

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted Bug or feature would be accepted as a PR or is being worked on proposal Proposal for a new functionality in Ocelot Service Discovery Ocelot feature: Service Discovery
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants