Thanks Oliver, the pact project and the vocabulary of consumer driven contract tests was super helpful.
One thing that came to mind when looking at the project was, that it just works against Ruby right now. Also, I am not certain if the approach is also applicable to larger API responses. The project also stores the 'pacts' as JSON under the hood, same direction as my proposal. So given we would establish a common base that also enabled elm-test to use such a system of 'mocking' the API through a predefined and verifiable fixture, how would that work in your imaginations? I'd imagine: - a piece of data in Elm, that represents the request, e.g. a HTTP statement, could map to the mocked payload somehow? - we need to declare the 'API state' that we'd like to simulate (analogous to what the part-time does) We definitely need to pass the mocked response through all the decoders, so the seam would be somewhere around the runtime handling Cmds, I'd think What are your thoughts around this? -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
