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

fix(multistream-select): remove cyclic dependency to libp2p-core #4090

Merged
merged 1 commit into from
Jun 20, 2023

Conversation

thomaseizinger
Copy link
Contributor

Description

All of the removed dev-dependencies are only for testing the upgrade procedure in libp2p-core. Ironically, this test does not use a single API of multistream-select. Thus, this test is simply misplaced in this crate. If we wanted to retain it, it should probably go into libp2p itself as that one already depends on all required crates.

Related: #4053.

Notes & open questions

Change checklist

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • A changelog entry has been made in the appropriate crates

Copy link
Member

@mxinden mxinden left a comment

Choose a reason for hiding this comment

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

With #3563 in mind, I am fine moving forward here. Agreed with your argument, that this is already tested through other tests in the workspace.

For the lack of a better term, I would call this a hierarchy-violating test, i.e. a test that needs a downstream crate to function. I wonder whether we should consider such tests a code smell across the code base.

@mergify mergify bot merged commit 755de30 into master Jun 20, 2023
@mergify mergify bot deleted the fix/remove-cyclic-dependency branch June 20, 2023 05:41
@thomaseizinger
Copy link
Contributor Author

For the lack of a better term, I would call this a hierarchy-violating test, i.e. a test that needs a downstream crate to function. I wonder whether we should consider such tests a code smell across the code base.

We had the same issue in the past with transport crates using libp2p-swarm.

I consider this an anti-pattern. IMO, we should look at crates individually and test their APIs regardless of how they are used in upper layers.

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

Successfully merging this pull request may close these issues.

2 participants