Re: [RFC] API Testing

Hey Charles!

Thanks for those links. I will definitely look at them as I haven’t read them before. I intend to write a post myself to shed some more light.

Right off the bat, let me just say that while potentially other for other languages than Hydra would be a great benefit, OpenAPI may not qualify because it’s essentially a  static description AFAIK. HAL (+ HAL-Forms maybe?) definitely does as it is a media type and not a description language. The kind of testing I propose would require runtime hypermedia, which OpenAPI alone does not provide.

Regards,
Tom


On 20 June 2019 at 16:00:46, Charles Vardeman (charles.vardeman@gmail.com) wrote:
> Greetings,
>  
> So, I really like the idea of having a DSL based testing tool that could
> potentially be extended to include other API definition languages (OpenAPI.
> HAL, etc). One thing I wonder is could some of the SHACL vocabulary also be
> reused to specify constraints on the API in your DSL specification. I also
> wonder how this fits into Ruben Verborgh's vision outlined in his recent
> blog post (
> https://ruben.verborgh.org/blog/2019/06/17/shaping-linked-data-apps/) and  
> TBLs post https://www.w3.org/DesignIssues/Footprints.html. It would seem
> that there may be some overlap between what you are proposing and these
> other efforts that could be leveraged?
>  
> Best,
> --Chuck
>  
> On Thu, Jun 20, 2019 at 3:14 AM Tomasz Pluskiewicz wrote:
>  
> >
> > Hello Hydra
> >
> > At Zazuko, we have recently started drafting a testing DSL dedicated to
> > Hypermedia APIs. At this point it naturally focuses on Hydra but
> > technically any hypermedia API could be tested in a similar manner.
> >
> > The difference from other HTTP API test tools I know is the focus solely
> > on links and form (operations). The tests should operate like a dynamic
> > client, where next steps are determined by nothing else but the resource
> > representations, ie. “follow your nose”.
> >
> > Why DSL? We’d like to offer a rich IDE support, although it should not be
> > necessary. It will be “compiled” to a more technical form, later to be
> > processed by a test runner.
> >
> > Please have a look at this gist [1]. I’d like to hear your thoughts. I
> > know that not everything is entirely clear ATM; I will be happy to answer
> > any questions.
> >
> > As first implementation I extend the code behind hydra analyser [2], [3]
> > to consume the description and run tests against an API.
> >
> > Best,
> > Tom
> >
> > [1]: https://gist.github.com/tpluscode/2f32c7d488ea434960f2a9b1721bbc82  
> > [2]: https://analyse.hypermedia.app
> > [3]: https://github.com/hypermedia-app/hydra-validator
> >
> >
>  
> --
> —————————————————
> Charles F. Vardeman II, Ph.D.
> Computational Scientist, Center for Research Computing
> Research Assistant Professor, Computer Science and Engineering
> University of Notre Dame
> PO BOX 539
> 111C ITC Building
> Notre Dame, IN 46556
> charles.vardeman@gmail.com
>

Received on Sunday, 23 June 2019 18:13:39 UTC