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.
