ScalaDoc for postCondition method is correct?

[Luis Rodero-Merino]

Hello,

I'm checking how the functionality to test stateful systems with ScalaCheck works. In my tests I have found that the scaladoc of the postCondition(state: State, result: Try[Result]): Prop method in the Command trait seems wrong. That text states:

Postcondition that decides if this command produced the correct result or not, given the system was in the provided state before the command ran.

But in the tests I'm running I'm finding that the state passed as parameter to postCondition is the one the system is left after running the command. Thus, should not the scaladoc be corrected? Or I'm getting something wrong? (As I'm not sure I've not filled an issue yet in ScalaCheck github).

Thanks for your help,

[Rickard Nilsson]

Hi Luis,

Can you give an example of when this goes wrong for you? It sounds like
a bug to me.

If you look at the simple stateful test that is part of ScalaCheck's
test suite, you can see that the post condition is based on the input
state:
https://github.com/rickynils/scalacheck/blob/master/jvm/src/test/scala/org/scalacheck/commands/CommandsSpecification.scala#L57

/ Rickard

On 09/14/2015 11:14 AM, Luis Rodero-Merino wrote:
> Hello,
>
> I'm checking how the functionality to test stateful systems with
> ScalaCheck works. In my tests I have found that the scaladoc of the
> postCondition(state: State, result: Try[Result]): Prop method in the
> Command trait seems wrong. That text states:

> /Postcondition that decides if this command produced the correct result
> or not, given the system was in the provided state *before* the command
> ran./

>
> But in the tests I'm running I'm finding that the state passed as

> parameter to postCondition is the one the system is left *after* running

> the command. Thus, should not the scaladoc be corrected? Or I'm getting
> something wrong? (As I'm not sure I've not filled an issue yet in
> ScalaCheck github).
>
> Thanks for your help,
>

> --
> You received this message because you are subscribed to the Google
> Groups "scalacheck" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to scalacheck+...@googlegroups.com
> <mailto:scalacheck+...@googlegroups.com>.
> To post to this group, send email to scala...@googlegroups.com
> <mailto:scala...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/scalacheck.
> For more options, visit https://groups.google.com/d/optout.

[Luis Rodero-Merino]

Yes, given that example the scaladoc is right... then I must have a bug in my code, I guess.

In https://gist.github.com/lrodero/e5923dc6969b53814ce7 I've copied an example of the system I'm testing. It's a very dummy vending machine of soft drinks that accepts three commands, when each command is called the machine state is printed. The DrinksTesting object takes care of the testing. It contains three classes extending Command that represent the machine commands. In each of those command classes the postCondition method prints the state and result passed as parameters. Running the example I find things like:

RELOADING                                                                                                       <- Reloading machine

LOAD      Vector((SPRITE,84), (COKE,78))

VENDMACHI Map(SPRITE -> SoftDrinkData(336,0.0), FANTA -> SoftDrinkData(96,5.0), COKE -> SoftDrinkData(312,0.0)) <- Internal state before

VENDMACHI Map(SPRITE -> SoftDrinkData(420,0.0), FANTA -> SoftDrinkData(96,5.0), COKE -> SoftDrinkData(390,0.0)) <- Internal state after reloading

NEXTST Map(SPRITE -> SoftDrinkData(420,0.0), FANTA -> SoftDrinkData(96,5.0), COKE -> SoftDrinkData(390,0.0))    <- Calling to nextState()

RELOAD    Vector((SPRITE,84), (COKE,78))                                                                        <- Calling to postCondition()

PREVSTATE Map(SPRITE -> SoftDrinkData(420,0.0), FANTA -> SoftDrinkData(96,5.0), COKE -> SoftDrinkData(390,0.0)) <- prev. state

VENDMACHI Map(SPRITE -> SoftDrinkData(420,0.0), FANTA -> SoftDrinkData(96,5.0), COKE -> SoftDrinkData(390,0.0)) <- result

MISMATCH                                                                                                        <- :(

Best,

To unsubscribe from this group and stop receiving emails from it, send an email to scalacheck+...@googlegroups.com.
To post to this group, send email to scala...@googlegroups.com.

Visit this group at http://groups.google.com/group/scalacheck.
For more options, visit https://groups.google.com/d/optout.

--

---------------------------------------------
Luis Rodero-Merino
luis...@gmail.com
---------------------------------------------

[Rickard Nilsson]

Hi Luis,

The problem is that your state model is mutable (it uses a mutable map
`drinks` to model the available drinks).

Look here:
https://gist.github.com/lrodero/e5923dc6969b53814ce7#file-gistfile1-txt-L116.
The nextState call actually modifies the prevState object (by calling
`drinks += ...`). That is the reason you get a weird state value in your
postCondition.

The scaladocs for Commands.State says that the type must be immutable.
Testing a mutable system by modeling it with another mutable state model
would be difficult to get right.

For you the fix is likely just to change you immutable map into an
immutable one.


/ Rickard

> <mailto:scalacheck%2Bunsu...@googlegroups.com>
> <mailto:scalacheck+...@googlegroups.com
> <mailto:scalacheck%2Bunsu...@googlegroups.com>>.

> To post to this group, send email to scala...@googlegroups.com
> <mailto:scala...@googlegroups.com>

> <mailto:scala...@googlegroups.com

> <mailto:scala...@googlegroups.com>>.
> Visit this group at http://groups.google.com/group/scalacheck.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "scalacheck" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to scalacheck+...@googlegroups.com

> <mailto:scalacheck%2Bunsu...@googlegroups.com>.

> To post to this group, send email to scala...@googlegroups.com
> <mailto:scala...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/scalacheck.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --

> ---------------------------------------------
> Luis Rodero-Merino
> luis...@gmail.com <mailto:luis...@gmail.com>
> ---------------------------------------------

[Luis Rodero-Merino]

You are totally right. Sorry I overlooked that, and thanks a lot for your help.

To unsubscribe from this group and stop receiving emails from it, send an email to scalacheck+...@googlegroups.com.
To post to this group, send email to scala...@googlegroups.com.

Visit this group at http://groups.google.com/group/scalacheck.
For more options, visit https://groups.google.com/d/optout.

--

---------------------------------------------
Luis Rodero-Merino
luis...@gmail.com
---------------------------------------------