Unhandled condition in cash register problem

paying cash less than the price is not handled in spec

// example change to first test
checkCashRegister(19.5, 2, [[“PENNY”, 1.01], [“NICKEL”, 2.05], [“DIME”, 3.1], [“QUARTER”, 4.25], [“ONE”, 90], [“FIVE”, 55], [“TEN”, 20], [“TWENTY”, 60], [“ONE HUNDRED”, 100]]) ,’(0)\n’,
//should return an object.

You are going to have to show us your entire solution before we can offer any help.

it’s not required to handle it, the input is always a valid one based on given requirements

1 Like

EXAMPLE -
console.log(
cashRegister(19.5, 2, [[“PENNY”, 1.01], [“NICKEL”, 2.05], [“DIME”, 3.1], [“QUARTER”, 4.25], [“ONE”, 90], [“FIVE”, 55], [“TEN”, 20], [“TWENTY”, 60], [“ONE HUNDRED”, 100]])
)

The problem reported was in the specification.
How to find out ?
Write a test.

Change the 2nd parameter to a value less than the price.
i.e price = 19.5 - cash = 2.0
Run the test.
? Does the solution stop the fraud ?

Mitigation: Add to the spec definition text explaining that the cash and price is always valid so the student can ignore this and similar conditions
OR add a test and error message if cash is less than price
EXTRA CREDIT allow handling of free products

This is not a valid test case and is not one of the provided test cases.

There is a very simplified set of test cases we want the users to satisfy. We could make the project more complex, but I don’t see a reason to do so.

Sorry, I cannot see why this test is not valid.

It’s not in the set of run tests because I already have passed successfully all of those tests.

If I am working for an employer and I only apply the tests given but fail to extend the unit tests to cover known bugs, am I a black hat ?

I feel like there is some language barrier here or something like that. This isn’t a relevant question at all.


We have a series of test cases we want the user to meet. We decided to keep this set of test cases simple. New learners certainly find this project plenty difficult on its own without additional complexity.

You may decide to make this project more difficult for yourself. That is fine. But those test cases that you decided that you wanted to add are outside of the design scope for this project.

I don’t see a good reason to add more requirements to this project. Just because we can make the project more complex does not mean we must. This code will never actually run a real cash register, so it is fine that it is a simplified version of the problem.

You are right, I think that my use of proof of concept has hidden the solution.

Mitigation: Add to the spec definition text explaining that the cash and price is always valid so the student can ignore this and similar conditions

I had difficulty with this problem due to being unable to differentiate expected behavior in the spec text.

I had to use trial and error to discover the difference.

  1. CLOSED - can supply change from the till with some cash left behind.
    and
  2. OPEN - can supply change from the till but no cash left over.

This would probably be well received by the team. Have you used GitHub before?

This sort of thing can be reported as a GitHub Issue on freeCodeCamp’s GitHub repository.

Good idea, I’ll have a go

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.