Nice work Oliy. I especially liked the re-frame section as I work at Day8 on re-frame. I liked what you did with the HTTP handler, much cleaner :)
On Fri, Nov 11, 2016 at 1:15 AM Oliver Hine <oliyh...@gmail.com> wrote: > Hi Erik, > > One of the philosophies of Martian was that it was not a "closed" system > so that it made no demands on the server, and you can use it with servers > that aren't yours and can't be changed. What you're describing is very much > server-side testing, so Martian doesn't help directly there. > > However, the description of endpoints using metadata is exactly how > pedestal-api <https://github.com/oliyh/pedestal-api> works using Schema. > In pedestal your routes are just a data structure so it would be easy to > walk them, pull out the schema for the parameters of each handler and > exercise them using test.check. > This is quite an interesting idea that would work well for "pure" handlers > with no side effects, but once you add databases and things to the mix it > could get trickier. > > Let me know if you need any pointers on how to go about this. > > Oliy > > > > On Thursday, 10 November 2016 10:20:01 UTC, Erik Assum wrote: > > Hi Oliy, > > In some ways this resonates with a thought I’ve had for a while, which > sort of appeared while working on a spring-boot application in java. > > So in Spring-boot, you have classes annotated as controllers, methods > annotated as request handlers which indicate what params and such they take. > What I’d like (and which might very well exist, I haven’t researched this > yet) was a tool that exercised the methods in the controllers, directly > without involving http. > > So given something like this: > > @Controller > public class MyController { > > @RequestMapping(…) > public String helloWorld(@RequestParam(“name”) String name) { > return “Hello “ + name; > } > } > > I’d like something that found all the controllers, invoked the methods > annotated @RequestMethod with random data a la test.check > and just verify that they returned “okish”, where I will not define > “okish” for now. > > And of course, I’d like to do some of the same with my ring app, e.g. > inspect all the routes in compojure, call the handlers (which I should have > spec’ed) > and have them called with random test.check data and verify that return > “okish” > > I am aware of this being a huge oversimplification, with lots of pitfalls > and undefined behaviours, but I still find it an interesting idea. > > Erik. > > On 10 Nov 2016, at 10:56, Oliver Hine <oliy...@gmail.com> wrote: > > Hi all, > > I wrote a blog post on some more advanced use of Martian, a library for > abstracting HTTP integration with other systems. > > All these use cases leverage the fact that Martian separates your data > (the *what*) from the HTTP implementation details (the *how*) and lets > you get on with connecting systems in valuable ways. > > The blog post includes the following topics: > > - Generative testing of HTTP integration > - Integration with non-swagger APIs > - REST as a side effect: integrating Martian with re-frame > > You can read it all here: http://juxt.pro/blog/posts/advanced-martian.html > > Thanks, > Oliy > > https://github.com/oliyh/martian > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > > To post to this group, send email to clo...@googlegroups.com > > > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > > clojure+u...@googlegroups.com > > > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+u...@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Daniel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
