Documentation

Run a request through the test middleware stack. This applies the same middlewares that IHP.Server uses. Used for initial setup only - actual request params are handled in callActionWithParams.

Bracket-style mock context creation with proper resource cleanup.

Uses withModelContext to ensure the database pool is released when done. Prefer this over mockContextNoDatabase.

Example: Use with hspec's aroundAll:

tests :: Spec
tests = aroundAll (withMockContext WebApplication config) do
    it "should work" $ withContext do
        ...

Build a WAI Application from a MockContext for use with runSession.

This mirrors the middleware stack from run: errorHandlerMiddleware wraps the app to catch exceptions and render error pages. EarlyReturnException is caught inside runAction/runActionWithNewContext.

Combines withMockContext and initTestApplication into a single bracket.

Example: Use with hspec's aroundAll:

tests :: Spec
tests = aroundAll (withMockContextAndApp WebApplication config) do
    it "should work" $ withContextAndApp \application -> do
        runSession (testGet "/foo") application >>= assertSuccess "bar"

Like withContext but for specs using withMockContextAndApp. The WAI Application is passed to the callback.

Run a IO action, setting implicit params based on supplied mock context

Runs a controller action in a mock environment

Runs a controller action in a mock environment

>>> callActionWithParams CreatePostAction [("title", "Hello World"), ("body", "lorem ipsum")|
Response { .. }

Run a Job in a mock environment

Example:

Let's say you have a Job called JobPost that you would like to process as part of a test.

 let postJob <- fetch ...

 callJob postJob

Note that callJob doesn't set the Job status that is initially set JobStatusNotStarted, as that is done by the Job queue (see jobDidSucceed for example).

mockAction has been renamed to callAction

Get contents of response

Get HTTP status of the controller

Vault key holding a Middleware that test helpers like withUser use to override request vault entries (e.g. currentUserVaultKey) *after* the production middleware stack has run. callActionWithParams reads this key and wraps the controller innermost, so the override is guaranteed to be the last writer — sidestepping sessionMiddleware/authMw, which would otherwise clobber the mock state.

Set's the current user for the application

Example:

user <- newRecord @User
    |> set #email "marc@digitallyinduced.com"
    |> createRecord

response <- withUser user do
    callAction CreatePostAction

In this example the currentUser will refer to the newly created user during the execution of CreatePostAction.

Internally this composes a Middleware into mockOverrideVaultKey that seeds currentUserVaultKey and currentUserIdVaultKey with the mock user. callActionWithParams applies that middleware *innermost*, so it runs after sessionMiddleware and authMw and wins on conflict.

Turns a record id into a value that can be used with callActionWithParams

Example:

Let's say you have a test like this:

 let postId = cs $ show $ post.id

 let params = [ ("postId", postId) ]

You can replace the cs $ show $ with a cleaner idToParam:

 let postId = idToParam (libraryOpening.id)

 let params = [ ("postId", postId) ]