avh4 / avh4/elm-program-test

Add ProgramTest.programTest

Open
#199 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Elm
Stars
95
Forks
28
PR merge metrics
No merged PRs in 30d

Description

At work, we've found a lot of success using `ensure*` functions for all of our tests. We had a period where we used both `ensure*` and `expect*` functions, but that created a lot of disparities between our helpers: we would have some helper functions to ensure property X without the equivalent the expect counterpart, or the other way around. We would also sometimes have divergent behavior in our helpers that had counterparts because for one test, we would have had to modify to "ensure" version and for some reason didn't update the "expect" version (or the other way around).

We ended up using the "ensure" pattern everywhere, as that one was the most polyvalent.
(I think if **I** were to design `elm-program-test` today, I would probably only provide the "ensure" pattern, but that's just my opinion based on my experience so far. It's also not the point for this issue, but happy to discuss more in a different issue.)

Using "ensure" everywhere meant however that we had to use `|> done` at the end of every one of our program tests:

```elm
test "invalid postal code shows a validation error" <|
\() ->
start
|> doSomeStuff
|> ensureViewHas [ expectations ]
|> done
```

We ended up providing a helper for all of our program tests that looks pretty much like this:

```elm
programTest : String -> (() -> ProgramTest model msg effect) -> Test
programTest description programTestFn =
Test.test description (\() -> programTestFn () |> done)
```

Example:
```elm
programTest "invalid postal code shows a validation error" <|
\() ->
start
|> doSomeStuff
|> ensureViewHas [ expectations ]
```

I suggest that such a helper is provided as part of this package's Elm API. Let me know what you think. I'd be happy to make a PR for this.

Contributor guide

Open the contributing guide

Research direction

Start by locating the Elm API entry point for ProgramTest and the existing `done` helper. Add the public `programTest` helper with the signature and behavior shown in the issue, then verify that the example can omit `|> done` while producing a Test. No specific file or test is named, so finding the relevant API module is part of the work.

Written by the indexing model from the issue text.

Assessment

Tech stack
elm
Domain
testing
Issue type
Feature
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
50/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.