-
Notifications
You must be signed in to change notification settings - Fork 701
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
testsuite: Add some unit tests for #9466 #9467 #9468
Conversation
70bf844
to
935383c
Compare
@Mikolaj Looking into this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense to open an Issue to refactor some of the tests to have more descriptive names?
I'm puzzled that people are so passionate about test names. I consider them the least important part of a test. A name isn't irrelevant, but I find the test code more important. The code is an executable specification.
https://blog.ploeh.dk/2022/06/13/some-thoughts-on-naming-tests/
cabal-install/tests/UnitTests/Distribution/Solver/Modular/Solver.hs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mpickering Thanks for writing these unit tests! I reviewed them based on our discussion in #9466 and #9467.
-- With the user constraint syntax (fails) | ||
setupStanzaTest1 :: SolverTest | ||
setupStanzaTest1 = userConstraints ["B test"] $ mkTest dbSetupStanza "setupStanzaTest1" ["A"] (solverSuccess [("A", 1), ("B", 1)]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does this test specify the constraint as a string? I would expect it to be equivalent to ExStanzaConstraint (scopeToplevel "B") [TestStanzas]
in the test below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The point of this test is testing the user constraint syntax and how UserConstraintSource
s influence the solver (7e44f76), and is otherwise equal to setupStanaTest2
below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I'll remove this test as well
cabal-install/tests/UnitTests/Distribution/Solver/Modular/Solver.hs
Outdated
Show resolved
Hide resolved
cabal-install/tests/UnitTests/Distribution/Solver/Modular/Solver.hs
Outdated
Show resolved
Hide resolved
cabal-install/tests/UnitTests/Distribution/Solver/Modular/Solver.hs
Outdated
Show resolved
Hide resolved
cabal-install/tests/UnitTests/Distribution/Solver/Modular/Solver.hs
Outdated
Show resolved
Hide resolved
cabal-install/tests/UnitTests/Distribution/Solver/Modular/Solver.hs
Outdated
Show resolved
Hide resolved
cabal-install/tests/UnitTests/Distribution/Solver/Modular/Solver.hs
Outdated
Show resolved
Hide resolved
parseConstraint :: String -> LabeledPackageConstraint | ||
parseConstraint str = | ||
case explicitEitherParsec parsec str of | ||
Left err -> error ("Bad user constraint: " ++ err) | ||
Right user_constraint -> toLpc (userToPackageConstraint user_constraint) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that we should add all types of constraints to the solver DSL rather than parsing strings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using strings for this particular case seems like an added benefit to me: the ability to easily add user constraints to the solver testsuite in the way that they are typically written, which doubles as a validation of the syntax parser. (unlike e.g. specifying (installed) packages and their dependencies for which the DSL is amazing to write concise tests, I don't think we'd win much by using a different syntax for user constraints which are already their own "canonical" concise way of being specified)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that we should test UserConstraint
s or parsing in this test suite, since that functionality is part of the cabal-install package, and these unit tests are for the dependency solver. These tests should eventually be moved to the cabal-install-solver package as a followup to #7358. I also think that it is confusing to have two ways to specify the same constraints.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see how that is reasonable. I'm going to drop the UserConstraint syntax testsuite support and change the tests to use PackageConstraints directly.
8ee7347
to
7e503eb
Compare
@grayjay I have addressed your review, could you check again? I think this is ready to merge. |
Very good, I've checked that our follow-up PR implementing private dependencies does fix this test that is marked expected broken: https://github.com/haskell/cabal/actions/runs/8270104380/job/22626918468?pr=9743 @grayjay a light ping |
cabal-install/tests/UnitTests/Distribution/Solver/Modular/Solver.hs
Outdated
Show resolved
Hide resolved
cabal-install/tests/UnitTests/Distribution/Solver/Modular/Solver.hs
Outdated
Show resolved
Hide resolved
cabal-install/tests/UnitTests/Distribution/Solver/Modular/Solver.hs
Outdated
Show resolved
Hide resolved
parseConstraint :: String -> LabeledPackageConstraint | ||
parseConstraint str = | ||
case explicitEitherParsec parsec str of | ||
Left err -> error ("Bad user constraint: " ++ err) | ||
Right user_constraint -> toLpc (userToPackageConstraint user_constraint) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that we should test UserConstraint
s or parsing in this test suite, since that functionality is part of the cabal-install package, and these unit tests are for the dependency solver. These tests should eventually be moved to the cabal-install-solver package as a followup to #7358. I also think that it is confusing to have two ways to specify the same constraints.
baf4564
to
f3f1e11
Compare
@grayjay ready to go. I've addressed your review fully. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
…eraction) This adds two tests for issue haskell#9467
These tests check how constraints interact with the --independent-goals flag.
…anza flags These tests check how the setup qualified scope interacts with the stanza flags (specified on the top-level and with the any qualifier)
@Mergifyio backport 3.12 |
✅ Backports have been created
|
* testsuite: Add tests for #9467 (base shim, setup qualifier interaction) This adds two tests for issue #9467 (cherry picked from commit 3851043) * testsuite: Add two tests for independent goals (#9466) These tests check how constraints interact with the --independent-goals flag. (cherry picked from commit b169cd4) * testsuite: Add some tests for setup component scope interacts with stanza flags These tests check how the setup qualified scope interacts with the stanza flags (specified on the top-level and with the any qualifier) (cherry picked from commit 573c15d) --------- Co-authored-by: Matthew Pickering <[email protected]> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
These commits add some tests I wrote when thinking about #9466 and #9467.