How do I write integration tests for Yesod handlers that call out to other services?

[Jason Whittle]

I’m using Yesod to write a REST API server that calls out to another REST API server as part of many of its handlers using http-conduit. I’ve been following the example set by the scaffolded tests in writing integration tests for my handlers, which works great if the only set-up I need to do for my test is alter the database state. 

How do I test Yesod handlers that make calls to an external API server without actually hitting the external server? To be clear, I can write the handlers so that they make the correct calls to the external API, I just haven’t figured out how to isolate that aspect in testing. I read Unit Testing IO in Haskell which sounds like what I’m looking for, except I want to make it work in yesod-test. 

[Michael Snoyman]

There are lots of ways to cut this, but ultimately it will come down to:

* Add a field to your App datatype indicating whether to do real calls or fake calls

* Set that appropriately from both the real applications and the test runner

You could either make it a boolean field and add fake-call logic throughout your application, or provide a function in your App data type for performing the calls and then mock it out. I'd probably lean towards the latter to centralize the mocking logic.

On Thu, May 19, 2016 at 7:24 PM Jason Whittle <jasonw...@gmail.com> wrote:

I’m using Yesod to write a REST API server that calls out to another REST API server as part of many of its handlers using http-conduit. I’ve been following the example set by the scaffolded tests in writing integration tests for my handlers, which works great if the only set-up I need to do for my test is alter the database state. 

How do I test Yesod handlers that make calls to an external API server without actually hitting the external server? To be clear, I can write the handlers so that they make the correct calls to the external API, I just haven’t figured out how to isolate that aspect in testing. I read Unit Testing IO in Haskell which sounds like what I’m looking for, except I want to make it work in yesod-test. 

--
You received this message because you are subscribed to the Google Groups "Yesod Web Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to yesodweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jason Whittle]

Thank you, Michael, I appreciate the guidance. 

Is anyone aware of an example of this set-up in a public repository? 

Cheers, 

Jason Whittle

[Jason Whittle]

Thank you, Michael, I followed your advice, adding a function to my App type, setting it to be the real function in makeFoundation, and then overriding it with a mock within each test. However, when I do this, the handler still uses the actual function, rather than the mock function provided for it. Where in the yesod-test hierarchy should I override the App so that the handler sees the mock? 

For more detail, I have written out the relevant code at http://stackoverflow.com/questions/39259340/how-do-i-modify-my-yesod-app-during-a-test

Thank you. 

Cheers, 
Jason Whittle

On Sunday, May 22, 2016 at 12:08:36 AM UTC-4, Michael Snoyman wrote:

[Christopher Allen]

One thing I would add is that it may be a good idea to make the mock
version of the function log that it was invoked, perhaps at a "debug"
loglevel in case you need to debug that later.

I do think function > boolean for this use-case. Debugging lattices of
boolean flags makes me twitchy.

--
Chris Allen
Currently working on http://haskellbook.com

[Jason Whittle]

Thank you for the suggestion, Chris. If I can get this thing to work, I plan to make the pieces I’m creating publicly available, at which point I hope you’ll take a look at it. 

One issue with your suggestion is that logging in the mock is complicated by the fact that the function type that is part of App returns an IO action. I ended up doing this because I couldn’t figure out how to have the function in App return a Handler action. 

Cheers, 

Jason Whittle

[Michael Snoyman]

IIUC, you just need to override the field at a different spot in the code. Using the scaffolded site as an example, I'd override here:

https://github.com/yesodweb/yesod-scaffold/blob/68ec6af22248de6c2a00e63624c34350846557cf/test/TestImport.hs#L35

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

[Jason Whittle]

Thank you for the suggestion. I stuck the creation of an MVar in the location you suggested and made the mock function use the MVar. The problem I ran into then was that I couldn’t find a way to pass the MVar to the body of the spec. What I ended up doing was to create an alternative to Yesod.Test that does everything exactly the same, except that it also passes around a mock in a manner similar to how it passes around the site. 

Is this something that people would be interested in having added to the yesod-test package? 

Cheers, 
Jason

[Jason Whittle]

For future readers: If you get to this point and want more information about how I addressed this issue, I answered my own question with further details at http://stackoverflow.com/questions/39259340/how-do-i-modify-my-yesod-app-during-a-test/39357087 and the modified code for Yesod.Test can be found at https://github.com/yesodweb/yesod/pull/1274. 

Cheers, 
Jason Whittle