Testing

gansey mod test <folder> loads the module (and the modules it requires, from folders beside it) and runs every fn test_…(ctx) in its tests/*.gansey files on the module's own thread, so a test can call the module's functions directly. A test passes unless it fails an assert or assert_eq, returns Err, or hits an error; what it prints is shown under it.

fn test_a_good_submission_is_kept(ctx) {
  let res = ctx.test.post("/forms/contact", { form: { _token: ctx.forms.token("contact"), name: "Ada" } })?;
  assert_eq(res.redirect, "/forms/contact/thanks");
  assert_eq(ctx.db.count("submissions")?, 1);
  Ok(())
}

ctx.test drives the module as the site would: get, post, put, patch, delete (path, { query, form, json, body, headers, cookies, user, ip }) answer the response map with its status; admin(title, { method, form, query }), card(title), widget(kind, settings), emit(hook, payload), job(name) and queue(name, payload) run the rest; style_sections() lists the theme style sections it declared, as the admin gets them; emails() lists what was sent in this test as { to, cc, bcc, reply_to, subject, body }: to a string (several addresses joined with ", "), cc and bcc lists (empty when none), reply_to a string or null. Core's own checks (sign-in, rates, cross-site) are not in between.

With --database <url> (or GANSEY_TEST_DATABASE_URL) the module gets real tables; each test starts with its declared tables empty and its store, queue and settings forgotten. Use a scratch database: the command refuses one that holds a site. Without one, ctx.db and ctx.store answer Err. --filter runs the tests whose names contain a word; --core 0.3.0 stands in for a coming core release when the manifest needs one. The forms module's tests/ folder (gansey-module-forms) is the example.