Re-design `allergies`
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Refactor
- Clarity
- Needs clarification
- Activity status
- Quiet
- Tech stack
- php
- Domain
- testing-qa
Research direction
Start by reviewing the current allergies exercise, its Allergen helper class, and the tests that use Allergen in a dataProvider. Compare the three enum and primitive-type suggestions, then define the chosen exercise and test design as done once the implementation no longer requires the problematic helper-class approach.
Written by the indexing model from the issue text.
Description
The current exercise design has many problems:
- Students must implement a helper class
Allergenthat has no TDD style guidance Allergenis used in tests, in a@dataProvider. That gives hard to understand PHP errors in tests onlyAllergenwould not be implemented that way anymore - it is a typicalenumclass
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?
- Dominant language
- PHP
- Stars
- 167
- Forks
- 151
- Avg merge
- 5h 50m
- Merged PRs (30d)
- 3
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- No pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from exercism/php
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
Discussion: Test generator designMay be free again @mk-mxp claimed this 395 days ago, and no pull request is open. Open
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Spomky-Labs/pwa-bundle#480 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 4 days
-
needs-triage Platform(Default)
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
ai-driven-fuzzing bug claude Major
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
Poetry updater rejects OR (||) Python constraints in PyprojectPreparer#update_python_requirementOpenL: python L: ruby:bundler
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
dependabot/dependabot-core#16819 ·
Maintainers usually reply within 1 day