avh4
Add `ensureModel`
There is expectModel : (model -> Expectation) -> ProgramTest model msg effect -> Expectation, but this necessarily "ends the test flow". This means there is no fall back way of doing something like "inspecting the model and the clicking a button".
So I think there is a missing function: ensureModel : (model -> Expectation) -> ProgramTest model msg effect -> ProgramTest model msg effect, analogous to the other ensure* functions.
This function may be particularly useful when attempting to debug a particular test to figure out why the test is failing.
Specifically for the debugging part of this, I'd generally like to improve debugging, see #88
For asserting something before clicking, I can imagine needing that for making some custom helper functions, though often when I need something like that it's because there's some other feature that elm-program-test is missing. If you had a specific scenario of needing this that you ran into, could you share a bit more about the specifics of what you're testing and what in the model is getting checked? The general approach I want to elm-program-test to encourage is to assert about something that's visible to the user in the view, or that's communicated to an external service via an effect, but I'm interested to know if there are scenarios where that's difficult or impossible to do.
Ah great, I hadn't seen that issue #88 previously.
I think I raised this more for the inconsistency in the API rather than a specific scenario, but see below. So it was more that all of the other expect* functions have an associated ensure* function but this one does not. It's a good argument to try to nudge consumers into asserting observable artefacts of the model in the view since that's what their end users ultimately care about. However, in that case why have expectModel at all? If it is to allow some missing feature to be worked around, wouldn't it be better to have ensureModel instead of expectModel because that way you could always work around the issue.
The specific way in which I was attempting to use this was regarding 'request statuses' on the model. So I wanted to check that when a request was sent the request status was set to InFlight and when the response was made it was set to Succeeded. Arguably I should be checking for a user observable effect of this, such as a visible 'working spinner'. Though what if the particular bug I was writing a regression test was "request status set to Succeeded but working spinner still showing" or "user posts downloading but working spinner not visible". More generally speaking I would think that an ensureModel function would allow you to write down your assumptions in the test, which allows the test to both fail quickly and help you determine why it is later failing. In particular it would be nice to write both assertions that the request status is set to 'InFlight' and the working spinner is showing, so that when it fails because the working spinner is not showing, you already know whether it is because the request status has not been updated correctly or because it is not being interpreted correctly, that is you know the bug is likely in the Update (if the request status has not been set) or in the view (if it has).
Just to add that I'm really enjoying working with elm-program-test thanks for creating the project it's very much appreciated.