Elm-program-test 3.0.0: new docs + support for HTTP and ports

I’m happy to announce the release of elm-program-test 3.0.0, which has been a long time in the making. New in this version is the ability to test programs that make HTTP requests and use ports, along with many other improvements.

There is also a new documentation site with guidebooks showing how to test programs with interactive views, test programs with Cmds, and test programs with ports.

And finally, there is a guide for upgrading from elm-program-test 2.x to 3.x for those who have already been using the package.


If you haven’t heard of elm-program-test before, it is designed to provides a convenient API that works with elm-test (including Test.Html) to test your Elm programs as complete units. Testing your programs at this level provides test coverage that is resilient even to drastic refactorings of your application architecture, and encourages tests that make it clear how end-users and external services will interact with your program.

Here’s a brief example of such a test (for more details about how to get started, see the new guidebooks.

test "successful registration" <|
    \() ->
        start
            |> fillIn "name" "Name" "Bailey Sheppard"
            |> fillIn "street-address" "Street Address" "14 North Moore Street"
            |> fillIn "postcode" "Postal Code" "12345"
            |> clickButton "Register"
            |> ensureViewHas [ text "Loading..." ]
            |> simulateHttpOk "POST"
                "https://example.com/api/v1/voter-registration"
                """{"status":1}"""
            |> Expect.all
                [ expectViewHasNot [ text "Loading..." ]
                , expectViewHas [ text "Registration successful!" ]
                ]

start =
    ProgramTest.createDocument
        { init = Main.init
        , update = Main.update
        , view = Main.view
        }
        |> ProgramTest.start ()

Thanks to @brookeangel for help with some of the new features, and to @mthadley and @glitteringkatie for code and documentation reviews. :pray:

51 Likes

This looks really cool and kinda makes me excited to try and set up some tests, which is a new feeling for me :slight_smile:

2 Likes

Cool. I will try this package on my next project.

1 Like

Great, glad to hear it!

And yeah, our team at NoRedInk has been finding that this sort of higher-level testing approach is a much clearer starting point for Elm tests than having to decide at what level to unit test things and when to test your view vs your update code. For many of our Elm pages, just having elm-program-test tests has been sufficient; and it’s only been a small number of places where a page is so complicated that it makes sense to split of a set of tests that only cover a smaller unit, so I’m pretty happy that this style of testing made the writing of tests for Elm pages a lot simpler in many cases.

1 Like

As I understand it, unit testing is more of a technique to help develop the correct code in conjunction with that code being written. This is why in XP the both the unit test and the code are written a little bit at a time, constantly switching between them - extend the test cases a bit, bring the code to a point where the test passes, repeat until done. Although XPers advocate doing this with all code, it does seem most applicable where you have a tricky algorithm to write.

Functional testing can be written before or after the code. Before to guide an implementation towards a desired behaviour, after to confirm its correctness. It also has the advantage of not constraining the implementation like unit testing does. 2 different units could be implemented quite differently and have different and non-exchangeable test cases, yet still be used to build the exact same behaviour.

Also gets us round the issue of not being able to create a Browser.Navigation.Key for unit testing purposes, so this is going to be very useful. :heart:

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.