Re-design `allergies`

[mk-mxp]

The current exercise design has many problems:

• Students must implement a helper class Allergen that has no TDD style guidance
• Allergen is used in tests, in a @dataProvider. That gives hard to understand PHP errors in tests only
• Allergen would not be implemented that way anymore - it is a typical enum class

Problem specifications do not ask for a certain implementation. They define the problem statement as open as possible. Our design also should allow as many solutions as possible.

Suggestion 1: Strings and integers only

This leaves all possibilities open. Mentors can suggest enum or such to students. But enum is optimal for interfaces, internal enum usage just complicates things.

Suggestion 2: Provide enum stub

In addition to the tests from problem specifications we test the enum implementation first. When that is implemented, the actual problem is tested for. In these tests we must use the enum type, too (like Allergen now).

This forces students to use enum. It raises the bar for students not familiar with that. But enum would be a good choice in a real life scenario.

Suggestion 3: Provide ready-made enum

As before, this forces students to use an enum type. But the level of required knowledge is lower (only usage is required). But still, it makes no sense to work with other types internally then.

Which way to go? Other suggestions?

[mk-mxp]

On 2024-08-18 another issue popped up: PHPUnit 10.5.30 A library used by PHPUnit introduced a change to assertEqualsCanonicalizing (all Canonicalizing assertions), which "was hiding problems with wrong expectations" - in our case the wrong expectation was to be able to compare objects in an array using this assertion. The documentation does not say "recursively" together with "canonicalized before they are compared". The wrong expectation was: Array keys don't matter when canonicalized. The documentation does not say anything about that, but it worked like that until now. See sebastianbergmann/comparator#113 for the change.

As a workaround, I pulled out the score from the objects to compare, as that is a differenciating property normalized the array keys before the assertion. This works with old and new library versions.

Edit: After identifying the real cause, rephrased the problem statement and the solution. Issue solved in #789

[tomasnorre]

I would go for solutions 3, Provide ready-made enum, as it's the "right" way to solve the problem in real life, but the one with enums that requires less for the student.