Creating a Resource for testing

[Fenntasy]

trafficstars

Hi,

I want to do some testing on my update function and it is kind of weird to test it when my model use a JsonApi.Resource as one of its field.

Let say, my model is

type alias Model =
    { vehicle : JsonApi.Resource
    }

Here is how I make my test

suite : Test
suite =
  let
      vehicle =
          decodeString
              JsonApi.Decode.document
              """{"data": {"type": "vehicle", "id": "1"}}"""
              |> Result.andThen JsonApi.Documents.primaryResource
  in
      describe "Internal update function"
          (case vehicle of
              Err err ->
                  [ test "Couldn't create JsonApi.Resource" <| \_ -> Expect.fail err ]

              Ok vehicle ->
                  let
                      model = { vehicle = vehicle }
                  in
                      [ test "NoOp should not change the model" <|
                          \_ ->
                              model
                                  |> Main.update Main.NoOp
                                  |> Tuple.first
                                  |> Expect.equal model
                      ]
          )

It seems awkward to have a case of in my tests and to manage the error case when I clearly know what I have in input. And I feel that I'm kind of abusing the test in my error case.

Is there something I missed, or a cleaner way of doing that?

[Fenntasy]

A solution to my problem might be something like an empty function that respond with an empty Resource.

That would allow to do something like this:

vehicle =
    decodeString
        JsonApi.Decode.document
        """{"data": {"type": "vehicle", "id": "1"}}"""
        |> Result.andThen JsonApi.Documents.primaryResource
        |> Result.withDefault JsonApi.Resources.empty

The thing is, looking at the specification

“Resource objects” appear in a JSON API document to represent resources.

A resource object MUST contain at least the following top-level members:

• id
• type

Exception: The id member is not required when the resource object originates at the client and represents a new resource to be created on the server.

Which is to say that, at least, the type must be present and to be able to differentiate ClientResource and Resource, it would need to accept a type(for a ClientResource) and an id (for a Resource).

Hence, I don't know if it would be a good idea to be able to produce a Resource, even an empty one, but I hope it is a lead.