• Forgetting to pass a custom class that’s persisted in your database in your JSDB.open() call now throws instead of corrupting your database by falling back to using an untyped object.
• Added JSDF ver. 2 to 3 database migration script (i.e., JSDB version 2-4 to 5)²
100% test coverage doesn’t mean your code’s bug free but it did just lead me to find and fix an issue in JavaScript Database (JSDB)¹ with a code path that wasn’t being hit that I would have otherwise missed because it was causing the relevant test to pass.
¹ JSDB is a zero-dependency, transparent, in-memory, streaming write-on-update JavaScript database for the Small Web that persists to a JavaScript transaction log (an append-only log).
To really drive home the above 👆 point that 100% test coverage does not mean ‘bug free’, just found a bug in JSDB¹ 5.0.0 where running JSON.stringify() on a complex custom object (actually: the automatic Proxy of the custom object created by JSDB) results in an error.
Already have a failing test and about to implement fix.
(It’s at this point where the test harness is invaluable.)