Snap Hspec testing - routes in snaplets

[Christian Goldammer]

Hi!

I'm using hspec-snap (https://hackage.haskell.org/package/hspec-snap-1.0.0.2/docs/Test-Hspec-Snap.html) to write unit tests for my snap application. I'm running into problems with routes. It's very possible that I'm overlooking something simple, many thanks for your help! My app looks roughly as follows:

app :: SnapletInit App App

app = do

  a <- nestSnaplet "api" api $ apiInit 

  addRoutes routes

  return $ App a

routes = [("login", handleLogin), ..]

The api snaplet has additional routes (using servant, but I don't think that should matter here). I can set up unit testing as follows:

tests = Test.snap (route routes) app $ do

  .. running tests here ..

But the problem is that, when I run these tests, only the routes that are specified as part of `routes` are reachable. I find this confusing. First of all, why are routes required? The `app` snaplet already adds routes. The bigger problem is that I can't reach the routes that are part of the nested `api` snaplet, so I don't have a way of testing that functionality.

Thanks, Chris

[Gregory Collins]

After staring at this for 20 minutes: I agree, this is confusing, but the confusing part seems to be in hspec-snap -- why would it expect you to provide a handler with routes? That's provided by the framework.

Test.snap should be using runSnaplet to get the app routes from the framework. Otherwise, as you've discovered, additional routes specified in the initializer routine will get blown away (because the resulting generated site handler is not invoked). Right now we are not exporting the routine needed in the public interface (here "is" is InitializerState which hspec gets from getSnaplet):

    let handler = runBase (_hFilter is $ route $ _handlers is) snapletMVar

We should probably export this function as a toplevel so hspec can use it.

--

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

--

Gregory Collins <gr...@gregorycollins.net>

[Daniel Patterson]

Yeah, as Greg said, one reason for this is that the functions to do this in a different way weren't exposed.

But, I think for testing, we actually want to do more than just get out the routes, we want to be able to modify the handler where requests are running. For example, you may want to log a user in (however that can be simulated to happen), and then run tests against that environment. So while I agree that the current system seems not ideal, I don't think just providing that function will be enough to replicate the current functionality. Probably producing a lens into some state would do it though.

(As a side note; I'm the author of the library, but I haven't used it, or Snap, in about ~2.5 years; I'm still doing baseline maintenance, i.e., merging pull requests and putting out Hackage releases, but if someone wants to take over maintenance, especially if there are going to be some redesigns to fix some of this stuff, that would be amazing...)