# Unit Testing “Where’s The Dollar?”

I was given the following riddle today. I thought I’d right a unit test in C# to “prove” it.

Three guys enter a hotel to stay for a night.  The desk clerk tells them that one room is \$30 per night.  This is perfect as there are three men — they each decide to pay \$10 a piece.  They each pay the money and head to their room.  A few minutes later, the clerk realizes his mistake as there is a special on rooms that week and they are only \$25 a night.  He gathers the five dollars and gives it to the bellboy to return to the men.  As the bellboy is riding the elevator, he thinks “There’s three men and five dollars, they’ll never be able to split it equally.  I’ll just keep two and they can have three to split equally.”  He keeps two dollars for himself and gives each of the men \$1 dollar in return.  Here’s the fun.  You have three men who paid 10 dollars a piece and received one dollar back….this means they each paid nine dollars.  The bellboy kept two dollars for himself.  So, nine x 3 equals 27 plus the 2 dollars the bellboy kept equals 29 dollars — where’s the missing dollar?

The quirk here is that there is one dollar unaccounted for. I wrote a unit test that proves in fact that there is a dollar missing. Therefore, this riddle has no answer.

`[Test]public void Wheres_the_dollar(){    // Initial Transaction    var FrontDesk = 30;    var GuyOne = 10;    var GuyTwo = 10;    var GuyThree = 10;    Assert.That(GuyOne + GuyTwo + GuyThree, Is.EqualTo(30));    // Correction    var BellBoy = 5;    FrontDesk -= 5;    Assert.That(GuyOne + GuyTwo + GuyThree - BellBoy, Is.EqualTo(FrontDesk));    // Reimbursement    BellBoy -= 3;    GuyOne -= 1;    GuyTwo -= 1;    GuyThree -= 1;    Assert.That(BellBoy + GuyOne + GuyTwo + GuyThree, Is.EqualTo(29));}`

The test passes, but obviously \$30 cannot be turned into \$29 without each bill’s location explained. Where is the flaw? Is it in the riddle, in the code, or in both?

Note: Consider this an exercise in turning real-world situations into code. ;)

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Oh hey, I'm a Senior Consultant for Headspring in Austin, TX. I've been working in software professionally since 2006 and I really, really love it. I'm mostly in the Microsoft world, but enjoy building computer things of all sorts (to be vague). When I'm not slinging code, I'm probably out and about slinging discs, bowling balls, or good beer with great friends.
• It’s in the riddle.

The men paid 27 dollars total, 25 of which went to the hotel, and 2 of which went to the bellboy. The error is in adding the amount of money the men spent to the amount of money the bellhop _received_. The amount of money received should be subtracted from the amount of money spent, and the values are equal.

• The last line should read:
Assert.That(GuyOne + GuyTwo + GuyThree – BellBoy, Is.EqualTo(FrontDesk));

The code is flawed in that GuyOne,Two,Three represent credits but bellboy and frontdesk represent debits (or the vice versa, I forget which).
Either way, your intransient condition is that no money is created in the system, i.e. bell + guys + frontdesk = 30

• @David

You’re correct in the flaw in the riddle. It is asking you to add money spent with money earned. Like saying that if I gave you \$1 and you earned \$1 from it, we have \$2. Which is just bad logic.

@Joshka

You’re also correct that the test is incorrect; the test falls under the same mistakes that the riddle enforces, the credit/debit actions cannot be added together like they are. The Front desk should start at \$0 if the guys start at \$10. This requires a rework of the tested logic, thus causing the test to fail.

• Matthew

The tests are also improper in their usage of certain numbers. The tests are written to prove or disprove equality conditions among variable expressions… testing if they equal 30, or 29 or 105 is poor design, and encourages the practical inadequacies of the test.

• @Matthew

You are correct, this is a poorly designed test, but note that it is tagged under “For Fun” ;)

• I think the point of the exercise was that you should always be careful when turning business requirements into code, no matter what method you use.