Final Capstone: Build a Quiz Engine · practice
Give One Response Useful Feedback
The blueprint can compare two
Build that behavior before adding input() or a
Define a small contract
Use one question record from the quiz plan:
question = {
"prompt": "Which keyword ends a loop?",
"answer": "break",
}
A focused response
result = response_result(question, " BREAK ")
Its result should carry two related facts:
whether the response was correct;
the feedback message to show.
A
{
"correct": True,
"message": "Correct!",
}
For an incorrect response, the False and the message can reveal the expected answer.
Why return data instead of printing immediately?
Returning a dictionary keeps this function usable in several contexts:
the interactive function can print its message;
the scoring loop can inspect its Boolean;
a test can check both fields without capturing
output.
The function performs one decision. Other functions will decide when to ask, display, and update the score.
Reuse the established comparison rule
Do not repeat .strip().lower() inside every new function. Call answers_match() so the whole quiz uses one answer policy.
If the policy changes later, one focused helper remains the source of truth.
Check both paths now
Use fixed values:
assert response_result(question, "break")["correct"] is True
assert response_result(question, "continue")["correct"] is False
This milestone stays non-interactive. That makes the return contract easy to understand before terminal input adds another moving part.
Why does response_result() return a dictionary instead of printing feedback itself?
Task
Implement the new response_result(question, given)
It must call answers_match(given, question["answer"]) and return:
{"correct": True, "message": "Correct!"}for a match;{"correct": False, "message": "Not quite. The answer is EXPECTED."}otherwise, using the question’s actual answer.
Keep your completed blueprint functions and the two prepared assertions. This milestone uses fixed responses and does not call input().