Add ProgramTest.programTest
- 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
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