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

testsuite: Add some unit tests for #9466 #9467 #9468

Merged
merged 3 commits into from
Apr 7, 2024

Conversation

mpickering
Copy link
Collaborator

These commits add some tests I wrote when thinking about #9466 and #9467.

@aleeusgr
Copy link
Contributor

@Mikolaj Looking into this PR.

Copy link
Contributor

@aleeusgr aleeusgr left a 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/

@grayjay grayjay self-requested a review January 4, 2024 08:58
Copy link
Collaborator

@grayjay grayjay left a 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.

Comment on lines 2536 to 2575
-- With the user constraint syntax (fails)
setupStanzaTest1 :: SolverTest
setupStanzaTest1 = userConstraints ["B test"] $ mkTest dbSetupStanza "setupStanzaTest1" ["A"] (solverSuccess [("A", 1), ("B", 1)])
Copy link
Collaborator

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.

Copy link
Collaborator

@alt-romes alt-romes Mar 11, 2024

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 UserConstraintSources influence the solver (7e44f76), and is otherwise equal to setupStanaTest2 below.

Copy link
Collaborator

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

Comment on lines 881 to 885
parseConstraint :: String -> LabeledPackageConstraint
parseConstraint str =
case explicitEitherParsec parsec str of
Left err -> error ("Bad user constraint: " ++ err)
Right user_constraint -> toLpc (userToPackageConstraint user_constraint)
Copy link
Collaborator

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.

Copy link
Collaborator

@alt-romes alt-romes Mar 11, 2024

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)

Copy link
Collaborator

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

Copy link
Collaborator

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.

@alt-romes alt-romes self-assigned this Mar 5, 2024
@alt-romes alt-romes force-pushed the wip/unit-tests branch 2 times, most recently from 8ee7347 to 7e503eb Compare March 11, 2024 14:46
@alt-romes
Copy link
Collaborator

@grayjay I have addressed your review, could you check again? I think this is ready to merge.

@alt-romes
Copy link
Collaborator

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

Comment on lines 881 to 885
parseConstraint :: String -> LabeledPackageConstraint
parseConstraint str =
case explicitEitherParsec parsec str of
Left err -> error ("Bad user constraint: " ++ err)
Right user_constraint -> toLpc (userToPackageConstraint user_constraint)
Copy link
Collaborator

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

@alt-romes alt-romes force-pushed the wip/unit-tests branch 3 times, most recently from baf4564 to f3f1e11 Compare April 3, 2024 10:15
@alt-romes
Copy link
Collaborator

@grayjay ready to go. I've addressed your review fully.

Copy link
Collaborator

@grayjay grayjay left a comment

Choose a reason for hiding this comment

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

Thanks!

@alt-romes alt-romes added merge me Tell Mergify Bot to merge and removed attention: needs-review labels Apr 5, 2024
@mergify mergify bot added the merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days label Apr 7, 2024
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)
@mergify mergify bot merged commit cd9b1fd into haskell:master Apr 7, 2024
55 checks passed
@Kleidukos
Copy link
Member

@Mergifyio backport 3.12

Copy link
Contributor

mergify bot commented May 16, 2024

backport 3.12

✅ Backports have been created

mergify bot added a commit that referenced this pull request May 16, 2024
* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cabal-install: solver merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days merge me Tell Mergify Bot to merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants