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

Supply library-defined props with NewConnectionProperties #157

Merged
merged 5 commits into from
Jan 20, 2023

Conversation

slagiewka
Copy link
Contributor

Fixes #152

@slagiewka
Copy link
Contributor Author

I wasn't too sure about testing this. What would be your expectations for this? A simple check if NewConnectionProperties always returns the fixed set?

@Zerpet
Copy link
Contributor

Zerpet commented Jan 20, 2023

Thank you for the PR! Yes, I think a simple check to assert the existence of the expected keys and values would suffice. The keys platform and product should not change overtime. The key version is changing between releases, so we could assert that its value is a valid semver string.

@Zerpet Zerpet added this to the 1.6.0 milestone Jan 20, 2023
@slagiewka
Copy link
Contributor Author

Thank you for the PR! Yes, I think a simple check to assert the existence of the expected keys and values would suffice. The keys platform and product should not change overtime. The key version is changing between releases, so we could assert that its value is a valid semver string.

I added a test for both. However I'm not too sure about the version string being checked here. Ideally it would be valid whether or not we have something (e.g. NewConnectionProperties) using it and testing it on its own.

@lukebakken lukebakken requested a review from Zerpet January 20, 2023 15:24
@lukebakken lukebakken self-assigned this Jan 20, 2023
@lukebakken lukebakken self-requested a review January 20, 2023 15:24
Copy link
Contributor

@lukebakken lukebakken left a comment

Choose a reason for hiding this comment

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

Thank you for your contribution!

@lukebakken lukebakken merged commit 0e5fc13 into rabbitmq:main Jan 20, 2023
@Zerpet
Copy link
Contributor

Zerpet commented Jan 20, 2023

Thank you for the PR! Yes, I think a simple check to assert the existence of the expected keys and values would suffice. The keys platform and product should not change overtime. The key version is changing between releases, so we could assert that its value is a valid semver string.

I added a test for both. However I'm not too sure about the version string being checked here. Ideally it would be valid whether or not we have something (e.g. NewConnectionProperties) using it and testing it on its own.

I understand your point, and I think it's a matter of preference. I personally want my tests to be red when/if I do something (very) wrong, like setting the version string to foo. Similarly, I think it's ok to assert on values for product and platform, because these values become part of the contract when the constructor sets them; therefore, if we break this contract, tests should be red.

Thank you for your contribution!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow re-using default connection config (custom properties)
3 participants