Skip to content

tests: consume fortinet query() as a FeedResult (fix red main) - #292

Merged
spierenburg merged 1 commit into
mainfrom
fix/fortinet-filter-feedresult-test
Jul 26, 2026
Merged

tests: consume fortinet query() as a FeedResult (fix red main)#292
spierenburg merged 1 commit into
mainfrom
fix/fortinet-filter-feedresult-test

Conversation

@spierenburg

Copy link
Copy Markdown
Collaborator

Problem

main is currently red on the stdlib unittest check — test_fortinet_filter fails:

AssertionError: 1 != 2 : expected only the high-CVSS entry, got
  FeedResult(items=[['news', 'Fortinet: [Critical bug - CVSS: `9.8`]...']], errors=[])

Two latent problems, both surfaced once #290 made modules/fortinet/feed.py parse again (the tests couldn't run at all before, so this was never caught):

  1. FeedResult return. The FeedResult migration (c7acb1a) converted fortinet's query() to return feedutils.result(items, errors) but never updated this test, which still consumed the return value as a bare list. len() on the FeedResult namedtuple counts its two fields (items, errors) → 2, not the number of posts, so every assertion was off.
  2. Test isolation. feed.py imports its sibling feedutils; the test exec-loads feed.py by file path, so modules/ is only importable if an earlier test in the discovery order happened to put it on sys.path. Run alone, it errored with ModuleNotFoundError: feedutils.

Fix

Test-only:

  • Unwrap the return via feedutils.split_result() — the same boundary the main loop uses.
  • Add modules/ to sys.path in _load_fortinet() so the test runs standalone as well as under discovery.

No production code change. fortinet returning a FeedResult is correct — it's one of the 16 multi-source modules migrated in c7acb1a; the test had simply never been run against that contract.

Testing

python -m unittest tests.test_fortinet_filter4/4 pass in isolation; tests.test_fortinet_filter tests.test_feed_contracts tests.test_module_contracts20/20.

Follow-up to #290.

…tion

Two latent problems in test_fortinet_filter, both surfaced once #290 made
modules/fortinet/feed.py parse again (the tests could not even run before):

1. FeedResult return. The FeedResult migration (c7acb1a) converted fortinet's
   query() to return feedutils.result(items, errors) but never updated this
   test, which still consumed the return value as a bare list -- so len() on
   the FeedResult counted its two fields (items, errors) instead of the posts,
   and every assertion was off. Unwrap via feedutils.split_result(), the same
   boundary the main loop uses.

2. Test isolation. feed.py imports its sibling `feedutils`; the test exec-loads
   feed.py by file path, so modules/ is only importable if some earlier test in
   the discovery order happened to put it on sys.path. Add modules/ to the path
   in _load_fortinet() so the test runs standalone too.

No production code changes -- fortinet returning a FeedResult is correct (it is
one of the 16 multi-source modules migrated in c7acb1a); the test had simply
never been run against that contract.
@spierenburg
spierenburg merged commit 01300ff into main Jul 26, 2026
5 checks passed
@spierenburg
spierenburg deleted the fix/fortinet-filter-feedresult-test branch August 4, 2026 21:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant