Expand description
The suite this view must satisfy over every store it can be given.
§Why this is a library module rather than a test target
A view is written against ObjectStore and cannot tell which store it has. That
substitutability is the design, and it is the thing most likely to quietly stop being
true – a header derived from a field one backend populates and another leaves empty
looks correct in every test written against the first.
So the behaviour is asserted once, here, and every backend the crate can be driven with runs the identical cases: the in-memory reference, a real filesystem partition, and the composed namespace a daemon actually serves from. A backend that answers differently fails the same case the reference passes.
It is a library module for the same reason gfeh-store’s is: a test target can only
be run by this crate, and the point is that other crates – a daemon, an
integration suite, a future backend – can run the same cases against a store this
crate has never heard of.
§It speaks HTTP
Every case here issues a real request over a real socket against a real listener.
Calling the handlers directly would test the same code with the parts that have
actually been wrong – header formats, status codes, the exact bytes of a
Content-Range – removed from the loop.
§Running it
Implement Backend and hand it to run. Each case gets its own store, its own
listener, and its own exposure table.
struct Mem;
#[async_trait::async_trait]
impl Backend for Mem {
fn name(&self) -> String { "MemStore".into() }
async fn fresh(&self) -> Result<Target> {
let store = gfeh_store::MemStore::new();
Ok(Target { root: store.root(), partition: store.partition(), store: Arc::new(store) })
}
}
let report = conformance::run(&Mem).await;
assert!(report.is_conformant(), "{}", report.summary());There is deliberately no built-in backend here. This crate depends on gfeh-core and
nothing else – naming MemStore would mean depending on gfeh-store, which is the
one thing a protocol crate may not do, and a stub store written here to avoid that
would be a second in-memory implementation for the suite to quietly agree with.
Structs§
- Case
- A single behaviour the view must exhibit.
- Outcome
- What one case did.
- Report
- The result of running the suite against one backend.
- Served
- One case’s view, its exposure table, and a client pointed at it.
- Target
- A store to run one case against.
Traits§
- Backend
- A factory for stores under test.