The problem I see is that the tests are being generated from the code, so they'll always pass.
So, you say you can make a test that update Up 0 == 1. But how did we get that test? We got 0 from the initial value of the model, and 1 from evaluating update Up 0. So if we changed update, or changed the model, it would change the test! You've basically got "update Up 0 == update Up 0", which will always pass. Now, you could do something where you have a working version of your code, and you generate a set of tests and save it, and then use it as regression tests later on to make sure you don't accidentally change the behaviour of your program, but that's more complicated. Is that the sort of thing you meant? On Mon, Mar 6, 2017 at 4:49 PM, Will White <[email protected]> wrote: > The debugger has the model, msg and the new model. So if you tell it that > the new model is indeed the expected return value from update msg model, > it can write that test for you. To use Counter as an example: > > model = 0 > > update msg model = > case msg of > Up -> > model + 1 > Down -> > model - 1 > > My model starts as 0. I send Up, I get 1. This is as expected so I > accept. update Up 0 == 1 is now a test that the code has to pass. > > > I have raised this here as a feature request: https://github.com/ > elm-lang/virtual-dom/issues/75 (see also Peter Gao's comment). Can you > foresee any problems with this feature? Would it in fact be useless? I > don't have a lot of testing experience. > > -- > 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. > -- 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.
