fossology / fossology/fossology-python
Align and complete test-suite coverage across endpoint modules
- Dominant language
- Python
- Stars
- 15
- Forks
- 18
- PR merge metrics
- No merged PRs in 30d
Description
### Background
Following the discussion in #196: the endpoint coverage has grown a fair bit recently, and the test suite would benefit from a pass to make coverage consistent across all modules.
The suite already combines two complementary approaches, and the idea here is to apply them uniformly rather than change them:
- **Live integration tests** against the Fossology test instance in CI (`fossologytests.yml`, `fossology/fossology:4.4.0`)
- **Mocked-request tests** (`responses`) for the API error paths
### Proposal
For each endpoint wrapper, aim for:
1. one live happy-path test validating the basic request/response against the CI Fossology instance, and
2. mocked tests for the documented error responses (e.g. `403` → `AuthorizationError`, `404`, `500`).
### Suggested steps
- [ ] Audit the endpoint modules (`folders`, `uploads`, `jobs`, `items`, `license`, `report`, `search`, `groups`, `users`) and list where a live happy-path test or a mocked error test is missing.
- [ ] Fill the gaps, following the existing patterns (`foss` fixture for live paths, `@responses.activate` for errors).
- [ ] Note the coverage convention briefly in the docs so new endpoints follow it.
### Non-goals
- No change to the CI setup or the pinned Fossology version.
- No new endpoints here (those stay in separate PRs).
I'm happy to take this on and split it into small per-module PRs if that's easier to review. Does this match what you had in mind, @deveaud-m?
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by auditing the endpoint modules named in the issue—folders, uploads, jobs, items, license, report, search, groups, and users—against their existing tests. Follow the `foss` fixture for live paths and `@responses.activate` for mocked errors, then check `fossologytests.yml` for the CI instance details. Done means each wrapper has the requested happy-path and error coverage, with the convention noted in the docs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- api, documentation, testing-qa
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100