[hcarter-775]

Description of Change

Seeding data did not work in one of the Zwave Lock test files. Because of this, one of the tests was only succeeding vacuously. Per Claude:

- Seed helpers: seed_users and seed_credentials now go through table_utils.add_entry, the way the users file does. Each call expects the matching capability event.
- Stubs: the proxy now gets the same log and supports_capability stubs as the users file, because add_entry needs them during seeding.
- Store reset: test_init now resets persistent_store and transient_store for every test. Without that, a credential seeded in one test showed up as an occupied slot in the next.
- deleteAllCredentials success test: it now expects the UserCode:Set AVAILABLE for index 1. The timers now match the driver's real schedule: one at 0s for the Set and one at 6s for cleanup. The old single 4s timer only worked because nothing was seeded.

Summary of Completed Tests

Test file changes.

[github-actions]

Channel deleted.

[github-actions]

zwave-lock_coverage.xml

File	Coverage
All files	87%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-lock/src/legacy-handlers/keywe-lock/init.lua	77%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-lock/src/lock_utils/tables.lua	98%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-lock/src/lock_utils/utils.lua	88%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-lock/src/lazy_load_subdriver.lua	57%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-lock/src/init.lua	93%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-lock/src/schlage-lock/can_handle.lua	75%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-lock/src/legacy-handlers/samsung-lock/init.lua	94%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-lock/src/legacy-handlers/zwave-alarm-v1-lock/init.lua	89%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-lock/src/samsung-lock/can_handle.lua	75%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-lock/src/lock_handlers/capabilities.lua	94%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-lock/src/lock_handlers/zwave_responses.lua	83%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-lock/src/zwave-alarm-v1-lock/init.lua	24%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-lock/src/keywe-lock/can_handle.lua	87%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-lock/src/legacy-handlers/schlage-lock/init.lua	95%	✅

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against 02b07c5

[github-actions]

Test Results

   73 files    545 suites   0s ⏱️
3 313 tests 3 313 ✅ 0 💤 0 ❌
5 313 runs  5 313 ✅ 0 💤 0 ❌

Results for commit 02b07c5.

♻️ This comment has been updated with latest results.

[cbaumler]

Left a few minor comments. Otherwise, LGTM.

nit: Unrelated to this diff: the find_all_entries_by shim at the top is dead since tables.lua defines it. Fine to drop here or in a follow-up.

nit: It looks like deleteAllCredentials: returns busy when another operation is already in progress calls seed_credentials but the test outcome doesn't depend on having seeded credentials. You could just remove the call from the test so that the timers aren't scheduled or you could advance the clock and expect the UserCode:set and cleanup events.

[cbaumler]

nit: Since the expected event is queued before add_entry, a failed seed will show up as an unrelated missing-message error later. Consider asserting the return value first and queuing the expectation only on success. Otherwise the assert message is the clearer failure.

[hcarter-775]

This issue here is that add_entry works synchronously, so unless the expectation is set prior to the event occurring, it will get marked as a failure