elm-test

During development, you can control which tests are executed using three functions. Note that using these results in an incomplete test run, which CI systems typically report as a failure to prevent accidentally committing a gutted test suite.

• only: Marks a suite so that only the tests within that block are run. Other tests in the suite are ignored.
• skip: Skips a specific test, even if it is inside an only block.
• todo: Marks a test as a placeholder for future implementation.

wipSuite : Test
wipSuite =
    describe "skip, only, and todo"
        [ only <|
            describe "Marking this test as `only` means no other tests will be run!"
                [ test "This test will be run" <| 
                    \_ -> 1 + 1 |> Expect.equal 2
                , skip <| test "This test will be skipped, even though it's in an `only`!" <| 
                    \_ -> 2 + 3 |> Expect.equal 4
                ]
        , test "This test will be skipped because it has no `only`" <| 
            \_ -> "left" |> Expect.equal "right"
        , todo "Make sure all splines are reticulated"
        ]

To write tests in Elm, use the elm-test package to define Test values. You can create hierarchical test suites using describe, write individual unit tests with test, assert results using Expect, and perform property-based testing with fuzz.

suite : Test
suite =
    describe "The String module"
        [ describe "String.reverse"
            [ test "has no effect on a palindrome" <|
                \_ ->
                    let
                        palindrome = "hannah"
                    in
                        Expect.equal palindrome (String.reverse palindrome)
            , test "reverses a known string" <|
                \_ ->
                    "ABCDEFG"
                        |> String.reverse
                        |> Expect.equal "GFEDCBA"
            , fuzz string "restores the original string if you run it again" <|
                \randomlyGeneratedString ->
                    randomlyGeneratedString
                        |> String.reverse
                        |> String.reverse
                        |> Expect.equal randomlyGeneratedString
            ]
        ]

When writing tests for Elm, consider these strategies:

• Prefer Fuzzing: Use fuzz to test properties of your code rather than just specific unit cases. For union types, map over all possible values.
• TDD Approach: Treat compiler errors as 'red' tests. Write the tests for functions that don't exist yet to drive your API design.
• API Design: If an API is hard to test, it is likely hard to use. Use your tests as your first client.
• Test Boundaries: Only test the exposed interface. Do not attempt to import unexposed functions just for testing purposes.
• Small & Focused: Keep tests small. Move setup code into reusable functions or custom fuzzers.
• Regression Testing: For simple functions, copying the implementation into the test can serve as a useful regression check.
• Documentation Integration: Consider using elm-verify-examples to turn your documentation examples into automated unit tests.