Business logic code for problem_user might have changed unintentionally?

[rkeeves]

TLDR

PR #44 did sweeping breaking changes due to refactoring.

I suspect one of those commits changed the business logic of problem_user.

As there's no specification, I cannot confirm whether this change is an improvement or a defect in the software.

Symptom A - problem_user stuck on ChekoutStepOne

1. Login as problem_user
2. Goto Cart
3. Goto CheckOutStepOne
4. Fill firstname
5. Fill zip
6. Type into lastname
7. See firstname mutated
8. See lastname non-mutated
9. Click Continue
10. See error

Background

This means that the problem_user:

• simply cannot submit this form ever
• will not really override into first_name, because on each keypress the entered char will be added to last_name (empty string) and that will be set to first_name

Pre-PR code and current master code are different:

• Pre-PR: sets fname + lname.
• current master: sets fname only notice the early return

Note that the new code blocks the problem_user from going into CheckOutStepTwo (form submissions is blocked), yet CheckOutStepTwo still has conditions about problem_user.

[diemol]

Thank you for taking the time to raise this issue.

This application is meant to be a sample and display happy paths and bugs to allow users to catch bugs through their testing. There are several places where bugs exist; this is intended, as this is simply a demo application.

[rkeeves]

Yep, I'll go away, just one last thing:

Here's a jest test from the repo.