Handlers are _named operations_, which can be exposed via routes.

Each domain module that exposes handlers does so through a `handlers` child module, ideally as a top-level symbol that can be plugged directly into Axum's `MethodRouter`. Modules could make exceptions to this - kill the doctrinaire inside yourself, after all - but none of the API modules that actually exist need such exceptions, and consistency is useful.

The related details of request types, URL types, response types, errors, &c &c are then organized into modules under `handlers`, along with their respective tests.

1 files changed, 0 insertions, 28 deletions

diff --git a/src/invite/routes/test.rs b/src/invite/routes/test.rs
deleted file mode 100644
index 4ea8a3d..0000000
--- a/src/invite/routes/test.rs
+++ /dev/null
@@ -1,28 +0,0 @@
-use axum::extract::{Json, State};
-
-use super::post;
-use crate::test::fixtures;
-
-#[tokio::test]
-async fn create_invite() {
-    // Set up the environment
-
-    let app = fixtures::scratch_app().await;
-    let issuer = fixtures::identity::create(&app, &fixtures::now()).await;
-    let issued_at = fixtures::now();
-
-    // Call the endpoint
-
-    let Json(invite) = post::handler(
-        State(app),
-        issued_at.clone(),
-        issuer.clone(),
-        Json(post::Request {}),
-    )
-    .await
-    .expect("creating an invite always succeeds");
-
-    // Verify the response
-    assert_eq!(issuer.user.id, invite.issuer);
-    assert_eq!(&*issued_at, &invite.issued_at);
-}