elm-test-journey aims to achieve most of the benefits associated w/ acceptance tests:
- Written from the user's perspective
- Independence from implementation
- Ensure proper interaction between components
while retaining most of the benefits of unit tests:
- Fast
- Type-checked
- Easy to debug
- Single threaded
elm-test install thematthopkins/elm-test-journey
See TodoExampleTest
Instead of mocking out low level Cmd's, the application under test defines an Effect type to represent all the side-effects your application can have.
This makes test writing much less error prone and easier to maintain by writing our tests in terms of type-checkable Effects, instead of expected Http requests or Ports made up of evil json and strings.
The page object pattern separates the test's knowledge of the HTML's structure from it's tests around the flow of the application. elm-test-journey enables you to easily define one for your application, which provides your tests more compile-time checks and better error messages, while reusing selectors.
See TodoExamplePage
elm-test-journey expects you to wrap your Ports in Effects. Unlike HTTP request though, ports are fire-and-forget and don't generate Msgs. When running TestJourney.handleEffect to handle Ports, you'll use TestJourney.EffectSeen instead of TestJourney.EffectProcessed to avoid dealing w/ Msgs.
elm-test-journey addresses these by using TestJourney.injectMsg. This allows you to simulate the Msg that your application would have created from the subscription.
This is where elm-test-journey's approach differs from elm-test-program. If you'd like to incorporate tests for these lower-level events more directly into your acceptance tests, elm-test-program may be a better option.