Tests: feeds that move, WordPress.com, Patreon and the catalogue #401
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Untested with both suites together: catalogue.rs's
follow_move(a permanent redirect updating the feed's address, 12 lines),list,url_stem,add/rmfrom the CLI; feed's wordpress.rswpcom_posts(the WordPress.com browser check answered through its API, #317, 58%) and patreon.rspatreon_shows(70%); scan.rs'sdownload_oneandreject. A feed that moves for good is common, and a wrong move loses a subscription's history.Tests to add:
feed_moved), subscriptions follow, and a temporary 302 changes nothing (fetch.rs has the redirect server)ipx addandipx rmchange the catalogue and subscriptions as the API doesSeen with the coverage of both suites merged line by line (cargo:
sh scripts/coverage.sh, browser:sh scripts/coverage.sh api; reports in target/coverage/cargo, api and page; #390, #394), as of 2026-11-07. A test added here shows in Grafana's Coverage row at the next run.Tests added in
c00d538. catalogue.rs: follow_move keeps the id and subscriptions, stores the new address in memory and the database, and leaves a feed whose new address another feed has, or one from an OPML; ipx add (title-named id, folder, keywords, refusing a duplicate, a second add with --list or a category changing only those) and ipx rm (catalogue and database). ipx-feed: a WordPress.com browser check through fetch() comes back as the REST API's posts; patreon_shows reads the campaign from the creator feed and asks the API, each show keeping the creator's credentials; a 404 is an error. Both APIs' base addresses go through api_base, a stand-in in tests. The 301/308-chain vs 302 rule was already tested in fetch.rs. Not done: scan.rs's download_one and reject.