test: fix failing unit_tests in test_namespace.py - #110
Conversation
The unit_tests CI job was red with ~40 failures, all in test/unittests/test_namespace.py. The production code in ovos_gui/ is correct; the tests had drifted from the actual API during the test rewrite (commit 249f196). Two distinct root causes: 1. ~30 failures: OSError [Errno 98] Address already in use. TestNamespaceManager.setUp builds a NamespaceManager(FakeBus()) once per test. NamespaceManager.__init__ calls create_gui_service(), which does application.listen(port) and binds a real websocket port. Without teardown, every test instance re-binds the same port and crashes. Fix: wrap the manager creation in `with mock.patch("ovos_gui.namespace.create_gui_service")` (the pattern the tests used before the rewrite). 2. ~10 failures: tests patched `self.namespace.send_message_to_gui` / `self.namespace_manager.send_message_to_gui` as instance attributes. send_message_to_gui is a module-level function imported into ovos_gui.namespace and called directly (always has been), so the instance mock was never invoked. Fix: patch the module-level function `ovos_gui.namespace.send_message_to_gui`. Also corrected three tests asserting a non-existent API: - test_handle_show_page asserted SYSTEM_ pages use template routing (_activate_namespace called with a site_id and _load_pages skipped). No such routing exists; SYSTEM_ pages are handled like any other page. Rewrote the block to match the real single-arg _activate_namespace and the actual _load_pages call. - Removed test_dispatch_template_to_adapters and test_gui_routing_key_default, which test _dispatch_template_to_adapters / _gui_routing_key / adapters members that do not exist anywhere in ovos_gui (the former also only had a tautological "called or not called" assertion). No production code, CI, or version files changed. test/unittests now: 88 passed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
More reviews will be available in 25 minutes and 47 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Hello there! I've processed your latest changes. 🌊I've aggregated the results of the automated checks for this PR below. 🔨 Build TestsThe compiler has spoken! Here is the verdict. 📜 ✅ All versions pass
Built by scripts, maintained by community 🤝 |
Summary
The
unit_testsCI job (matrix py3.9/3.10/3.11) was RED with ~40 failures, all intest/unittests/test_namespace.py. The production code inovos_gui/is correct; the tests had drifted from the actual API during the test rewrite (commit249f196). This PR makes the tests reflect current, correct behaviour. No production code, CI workflows, or version files are touched — onlytest/unittests/test_namespace.py.Root causes
1. ~30 failures —
OSError: [Errno 98] Address already in useTestNamespaceManager.setUpbuilds aNamespaceManager(FakeBus())per test.NamespaceManager.__init__callscreate_gui_service(), which doesapplication.listen(port)and binds a real websocket port. With no teardown, each test instance re-binds the same port and crashes. Fixed by wrapping the manager construction inwith mock.patch("ovos_gui.namespace.create_gui_service")— the exact pattern the tests used before the rewrite.2. ~10 failures — mock patched the wrong target
Tests patched
self.namespace.send_message_to_gui/self.namespace_manager.send_message_to_guias instance attributes.send_message_to_guiis a module-level function imported intoovos_gui.namespaceand called directly (it always has been, since 2023), so the instance mock was never invoked, yieldingnot called/NoneType is not subscriptable. Fixed by patching the module-levelovos_gui.namespace.send_message_to_gui.3. 3 tests asserted a non-existent API
test_handle_show_pageasserted thatSYSTEM_pages use template routing (_activate_namespacecalled with asite_id,_load_pagesskipped). No such routing exists inovos_gui;SYSTEM_pages are handled like any other page. Rewrote that block to assert the real single-arg_activate_namespaceand the actual_load_pagescall.test_dispatch_template_to_adaptersandtest_gui_routing_key_default, which exercised_dispatch_template_to_adapters/_gui_routing_key/ anadaptersattribute that do not exist anywhere inovos_gui. The former also only had a tautologicalassertTrue(x.called or not x.called)assertion.Result
python -m pytest test/unittests(the CI command) is fully green; the widertest/suite also passes with no regressions.🤖 Generated with Claude Code