Download Testing Infrastructure

[Integer-Ctrl]

Currently, only the download of a collection and downloads using SPARQL queries are tested, and these tests are very basic. To ensure reliability, the client needs more complete automated tests for all download features.

Proposed features:

• Improve existing tests
  • e.g., verify SHASUM of all downloaded files
• Test all download features and CLI options
• Add tests for intended failures (e.g., non-existing resources, missing permissions)

Advanced:
Currently, the download tests depend on the remote Databus server. This effectively makes them integration tests rather than isolated unit tests. A better approach would be to create a local dummy Databus for testing core functionality offline.
This could include:

• A local HTTP server simulating Databus responses
• A small dummy dataset with the structure account/group/artifact/version and a collection example to test all the download features

[Tahoora-Tabassum]

From my understanding, the current tests only cover a basic happy path and depend on the remote Databus, which makes them brittle and closer to integration tests.

Extending coverage (SHASUM checks, CLI options, failure cases) seems manageable, but the local dummy Databus feels like the main open question. Is there a defined scope for what needs to be mocked (specific endpoints / behaviors), or is a minimal HTTP server with a small static dataset sufficient?

[Integer-Ctrl]

Yes, that's a fair assessment, the current tests are very minimal and mainly cover basics. At the moment, there is no concrete plan or defined scope on how to proceed with extending or restructuring them.

Many issues like this were intentionally left open as "nice to have" or feature wishes (this one), but there are currently no dedicated resources for planning or structuring this work in more detail. Any help, proposals, or questions, especially in the form of a draft or initial approach, are very welcome and appreciated.

TL;DR: No, there is no defined scope for mocking the Databus right now. That said, a minimal approach sounds perfectly sufficient as a starting point.

[Tahoora-Tabassum]

Thanks for the detailed context.

To keep things manageable, I’ll start with a minimal, incremental approach rather than tackling the full testing scope at once.

As a first step, I plan to:

extend the existing download tests with stronger assertions (e.g. verifying SHASUMs of downloaded files),

add a small set of failure-case tests (non-existing resources, permission errors) where feasible.

For the Databus dependency, I agree that a full replacement would be more of an advanced step. I’ll therefore experiment with a very lightweight local HTTP mock that simulates only the Databus endpoints required by the current download logic, without aiming for full feature parity.

I’ll put together a short draft or initial PR reflecting this minimal scope so we can iterate from there based on feedback.