Add expectBroken test for #7423

[ffaf1]

Test (expected fail) for #7423

---

Please include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.

Please also shortly describe how you tested your change. Bonus points for added tests!

[ffaf1]

Lovely individuals, this does not pass CI and I suspect the problem is related to

**How do I mark a test as broken?**  Use `expectBroken`, which takes
the ticket number as its first argument.  Note that this does NOT
handle accept-test brokenness, so you will have to add a manual
string output test, if that is how your test is "failing."

↑ I understand little of this. If you point me to a working example I can update the documentation to make it a bit clearer too!

[ffaf1]

I have modified the test and now it should pass “expected fail” but I am still a bit confused:

• what does not handling “accept-test brokenness” mean exactly? That test that should pass without a warning/error (when not broken) are not handled by expectBroken?
• I have added a string output test as suggested. Is this correct? Is pointing that you can rewrite main in a simpler way once the test stops being broken correct?

(this was the offending line)

[fgaz]

what does not handling “accept-test brokenness” mean exactly? That test that should pass without a warning/error (when not broken) are not handled by expectBroken?

I think it means that --accept won't write the expected correct output to the golden file because it can't know what it'll be, so you have to write it yourself (like you did)

I have added a string output test as suggested. Is this correct?

Looks correct

Is pointing that you can rewrite main in a simpler way once the test stops being broken correct?

why can't we write it like that already?

[ffaf1]

If I write it like this (cabal.test.hs):

main = cabalTest . expectBroken 7423 $ cabal "check" []

I get an:

UNEXPECTED OK

Hence I wonder what I am doing wrong.

[fgaz]

Then I guess that's the meaning of this part:

so you will have to add a manual string output test, if that is how your test is "failing."

Looks like the expected output isn't checked at all with expectBroken, but that's the only way to tell if this test is failing since the -O2 warning isn't a fatal warning.

[fgaz]

What about checking that the output does not contain O2, and keeping that even after #7423 is fixed?

[Mikolaj]

@ffaf1: just checking: are you exasperated and you rage-quit this PR :) or have you decided to follow a different design?

[ffaf1]

Lol no I have just renamed the branch to a more appropriate name!

Maybe renaming locally and deleting the remote was not the proper course of action!

I will see if I can fix this or I will just open a new PR as soon as I am finished with the one I am writing (i.e.: writing a testsuite for current cabal check capabilities).

[Mikolaj]

No worries. :)