search

MichaelKentBurns / BibleModel

Data model / database containing complete text of the Bible, Cross References, Notes and other references
3 stars 0 forks source link

We need a robust set of unit tests written. #4

Open MichaelKentBurns opened 2 weeks ago

MichaelKentBurns commented 2 weeks ago

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'.

michael@Logos BibleModel % npm test

biblemodel@1.0.0 test jest

console.log Bible.js Initializing for the first time

  at Object.log (Bible.js:29:31)

...

MichaelKentBurns commented 2 weeks 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:

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.

MichaelKentBurns commented 1 week ago

I was able to resolve the main problem and the basic unit test in Bible.test.js now works. There are still some issues, but the stateMachine does it's job, which at this point is producing and saving the books.json file.