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