Skip to content

Challenges

Jump to bottom
Hannah edited this page Feb 24, 2021 · 6 revisions

Challenges

Same Input, Different Output from one CashRegister

I was having an incredible bug in my unit testing only where I could pass a given "cash in drawer" array to a CashRegister, and receive half a $5 bill instead of the expected 2 quarters.

The most astounding thing is that the function passed the same test multiple times in all the other ways it had been tested: the unit tests on freeCodeCamp, in the console by running the script with Node, both transpiled, transpiled with preset, and not. But no matter what, that final test kept failing.

So after a night's sleep, I realized that I could copy-paste the original unit tests from freeCodeCamp into my own test suite to see what happened.

Lo and behold, the test copied directly from freeCodeCamp passed just fine. There must be some mistake that I made, then...

Even when I had copied exactly the input and the expected output into my test array, it was failing... So perhaps I had accidentally mutated the array when looping it...?

Finally a clue

Finally, after re-adding some console statements, I had a clue: the "faulty" unit test was decrementing the remainingBalance in the wrong order, starting with pennies instead of hundred dollar bills. Somehow, its input array representing the drawer of cash was being flipped at the beginning of the algorithm when all the other tests were not flipping it... Somehow the cash in drawer array is being flipped as it was given to the checkCashRegister function, at the very top of the algorithm

Back to the test suite: my next suspect was the double de-structuring that I was doing in the forEach loop... Perhaps that was... doing... something... to flip my array?

  testArr.forEach(([[price, cash, cid], expectedResult]) => {
    it(`should return ${JSON.stringify(expectedResult)} given ${price}, ${cash}, ${JSON.stringify(cid)}`, () => {
      assert.deepStrictEqual(
        checkCashRegister(price, cash, cid), expectedResult
      );
    });
  });

For reference:

[[...], expectedResult]: The first de-structuring, the outer array, is meant to refer to each array within testArr.

[[price, cash, cid], ...]: The inner array is meant to the refer to the array containing the inputs. Note that cid is also an array.

Alas, no... Removing the double de-structuring had no impact on the result.

  testArr.forEach(([input, expectedResult]) => {
    it(`should return ${JSON.stringify(expectedResult)} given ${JSON.stringify(input)}`, () => {
      assert.deepStrictEqual(
        checkCashRegister(input[0], input[1], input[2]), expectedResult
      );
    });
  });

To be continued...

Upgrading Node 14 and NPM 6

I upgraded my global npm from 6.14.x to 7.x and Node from 14.x to 15.x mid-project; this seemed to have overwritten global installations: daily-use commands, such as mocha or npm test: mocha, were now having issues.

Mocha

js-capstone $ mocha
Command 'mocha' not found, but can be installed with:
...

npm test

It wasn't just global dependencies acting up; local dependencies were popping up where they hadn't before.

23 verbose stack Error: command failed (...)
$HOME/.nvm/versions/node/v15.9.0/lib/node_modules/npm/node_modules/@npmcli/promise-spawn/index.js:64:27

npm ERR! code 1
npm ERR! path /mnt/d/freeCodeCampJS/js-capstone
npm ERR! command failed
npm ERR! command sh -c mocha

npm ERR! A complete log of this run can be found in:
npm ERR!     $HOME/.npm/_logs/2021-02-23T17_52_28_892Z-debug.log

The truncated contents of the debug log:

23 verbose stack Error: command failed
23 verbose stack     at ChildProcess.<anonymous> ($HOME/.nvm/versions/node/v15.9.0/lib/node_modules/npm/node_modules/@npmcli/promise-spawn/index.js:64:27)
23 verbose stack     at ChildProcess.emit (node:events:378:20)
23 verbose stack     at maybeClose (node:internal/child_process:1067:16)
23 verbose stack     at Process.ChildProcess._handle.onexit (node:internal/child_process:301:5)
24 verbose pkgid js-capstone@0.1.0
25 verbose cwd /mnt/d/freeCodeCampJS/js-capstone
26 verbose Linux 4.4.0-19041-Microsoft
27 verbose argv "$HOME/.nvm/versions/node/v15.9.0/bin/node" "$HOME/.nvm/versions/node/v15.9.0/bin/npm" "test"
28 verbose node v15.9.0
29 verbose npm  v7.5.4

To be continued...

Subsequent Install Fails with npm 7, React 17, and Google Firebase Hooks 2.2.0

NPM package react-firebase-hooks at version 2.2.0 it is associated with the following React 17 error message when trying to install dependencies.

npm i

npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving: js-capstone@0.1.0
npm ERR! Found: react@17.0.1
npm ERR! node_modules/react
npm ERR!   react@"^17.0.1" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer react@"^16.8.0" from react-firebase-hooks@2.2.0
npm ERR! node_modules/react-firebase-hooks
npm ERR!   react-firebase-hooks@"^2.2.0" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

(...)

Fix the upstream dependency conflict, or retry this command with --force, or --legacy-peer-deps to accept an incorrect (and potentially broken) dependency resolution

Apparently, a relevant difference between npm versions 3 to 6 and version 7 is that npm 7 will not ignore peer dependencies on installation. To reset the behavior of npm 7 in this regard, the --legacy-peer-deps flag can be added to the installation command: npm i --legacy-peer-deps

Finally, by using this flag, npm was able to install dependencies.

Clone this wiki locally