MichaelKentBurns
commented
1 day ago The first test written is in Bible.test.js and its purpose is to startup the Bible Model and let it get initialized and then make sure that the books array got loaded.
That simple unit test (and my adhoc testing) show that in my recent refactoring of Bible.js I have somehow broken the state machine.
There are two ways to run tests to reproduce this:
node Bible.js >&Notes/runs/Bible.js-2024-11-06.run
and
npm test >&Notes/runs/jest-2024-11-06.run
The normal node execution as well as simply running Bible.js in VS Code show that after all of the "Bible.js Book added:" lines indicating that the books query has been fully processed the StateMachine recognizes that all 66 books are processed, and the list is complete the state machine (records that fact twice) and then just quits. It also indicates that the next state (4 booksLoaded) is triggered, but the state machine just stops when it should simply proceed to state 4 and others after that.
But, the jest run gives more information:
console.log Bible.js ===================== stateMachine() ending. time= 366.747833
at log (Bible.js:309:29)● Cannot log after tests are done. Did you forget to wait for something async in your test? Attempted to log "nextTick callback".
This confirms that the state machine just stopped (ie returned from Bible.js to the jest test. However the actual process kept logging (eg. "nextTick callback" and more. Each occurrence of that contains the very helpful clue:
- ● Cannot log after tests are done. Did you forget to wait for something async in your test? Attempted to log "Bible.js state is waiting for books to be done loading.".
This is one of the features of JEST and thus its value beyond adhoc testing.
So, now I need to look at the changes I made recently where I must have dropped a call to wait for the promise. So, now, I am looking at the recent changes to figure out how I broke it.
Inspecting my saved runs: specifically TestStatesAndAsych-2024-10-02.run (where it worked properly, and Bible.js.trace.run.2024-11-01.run where it failed.
Unfortunately I did quite a bit of work between those times, and did not do consistent testing.
LET THIS BE A LESSON to ME and you, dear reader:
1) Use your unit testing and save results more often.
2) Do frequent commits when doing extensive work. I was working on a number of issues, and failed to do smaller commits. So, I don't know which changes did the breakage.
3) Run your unit tests BEFORE doing a commit to make sure that commit does not break things. And only do the commit when the unit tests all pass.
So, now what I have to do is carefully inspect every change made during that period and see if I can find the problem. That effort will be recorded in my next comment here.
I have chose Jest as a unit test framework. See https://jestjs.io It is a simple npm install for jest. In that site, choose the Docs section from the title bar. It shows how to install and write tests. Look for sources that end in .test.js. For instance one unit test file for Bible.js is Bible.test.js. You can then run it by simply entering the command 'npm test'.