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...)

On Thu, Feb 22, 2018, at 10:11 AM, Gregory Collins wrote:
> 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.> 
> 
> On Mon, Feb 19, 2018 at 12:42 PM, Christian Goldammer
> <goldammer.christ...@gmail.com> wrote:>> 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
>> 
>> 


>> --
>>
>>  ---
>>  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+unsubscr...@googlegroups.com. For more options, visit
>>  https://groups.google.com/d/optout.> 
> 
> 
> -- 
> Gregory Collins <g...@gregorycollins.net>

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to