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?