Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IO in expectAny expectation constructor predicate #30

Open
tim2CF opened this issue Sep 9, 2022 · 1 comment
Open

IO in expectAny expectation constructor predicate #30

tim2CF opened this issue Sep 9, 2022 · 1 comment

Comments

@tim2CF
Copy link

tim2CF commented Sep 9, 2022

In this example I can see that PollChat_ expectation constructor accepts Predicate, in this case anything. Is there the good way to use IO-like expressions (with side effects) to create predicates (like anything)? Sometimes it would be super useful to call database/webservice hosted in local test environment to verify that argument is genuine. This especially useful in cases where code which is tested is using some sort of randomness involved, for example request should be always unique due dynamically generated nonce and signed on top of it with some private key. I hope I manged to explain the use case. Best regards!

        expectAny $
          PollChat_ anything
            |-> (User "A", "I love Haskell")
            |-> (User "B", "Lovin' the ass. candies")
            |-> (User "B", "!leave")
@cdsmith
Copy link
Owner

cdsmith commented Oct 16, 2022

Sorry to miss this! I'm looking now.

One thought here is that logically, predicates should be pure. You are describing a case where you have a predicate that's sort of "morally pure" in the sense that you don't care to track the I/O. Well, that's precisely what unsafePerformIO means, and you can certainly construct a Predicate using is from explainable-predicates along with unsafePerformIO.

The counter-argument would be, I suppose, that you really do care about the effect. In the example of looking something up in a database, you actually want to specifically check that it's in the database when the action is performed, and not at some other arbitrary time. So my initial reaction is probably wrong. I suppose this argues for either extending explainable-predicates to handle predicates with effects, or offering some HMock-specific alternative. I'm leaning towards the latter at the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants