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, 27 insertions, 0 deletions

diff --git a/src/invite/handlers/issue/test.rs b/src/invite/handlers/issue/test.rs
new file mode 100644
index 0000000..2bf5400
--- /dev/null
+++ b/src/invite/handlers/issue/test.rs
@@ -0,0 +1,27 @@
+use axum::extract::{Json, State};
+
+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) = super::handler(
+        State(app),
+        issued_at.clone(),
+        issuer.clone(),
+        Json(super::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);
+}