- From: László Lajos Jánszky <laszlo.janszky@gmail.com>
- Date: Wed, 27 May 2015 08:20:51 +0200
- To: "Sinnema, Remon" <remon.sinnema@emc.com>
- Cc: "public-hydra@w3.org" <public-hydra@w3.org>
Hi Ray! Nice article! :-) What I meant that the test code of the domain logic can be used to generate a REST adapter and e2e tests for the REST API (which can be later used to write a REST API specific client). The scenarios can be the same by both, only the world (the step definitions) should change. Your approach to map the steps to the REST API is nice and probably it can be used to generate the REST adapter. (Note that "s/he" is recommended by gherkin instead of "I", and the "Given the RESTBucks service" is completely unnecessary. "Given a (RESTBucks) customer called John" would be a much better start. But this is a bit off topic here, and it does not really matter anyways, the mapping is good.) The problem, should be solved here, that the "When I create an order for a large, semi milk latte for takeaway" step is not machine processable into "POST /orders/ {size: "large", coffee: "semi milk latter", "take-away": true}". To do that we need annotations, or REST adapter specific step definitions (helpers hereafter), which contain additional info, e.g. URI template, HTTP method, etc.. It is inferable more or less, e.g. "When" means we are talking about a link, "create" means the method is POST (or PUT), etc... but it is better to decouple the scenario description from these implementation details, so use annotations or helpers. Helpers might be a better choice, since too many annotations in the scenario description would be too noisy (would worsen understanding). I think it is a nice thing, at least in theory, that's why I started this discussion, maybe somebody thinks about it in more detail, and probably implements it. Have a nice day, Leslie 2015-05-26 8:32 GMT+02:00 Sinnema, Remon <remon.sinnema@emc.com>: > Hi László, > > I noticed this similarity too and blogged about it last year: > http://securesoftwaredev.com/2014/07/01/behavior-driven-restful-apis/ > > > Thanks, > Ray > > >> -----Original Message----- >> From: László Lajos Jánszky [mailto:laszlo.janszky@gmail.com] >> Sent: Monday, May 25, 2015 4:02 AM >> To: public-hydra@w3.org >> Subject: cucumber could be used to generate a REST API? >> >> I have found some interesting overlaps between the gherkin >> https://github.com/cucumber/gherkin3 >> and hydra vocabs: >> >> gherkin:Feature ~ hydra:Operation feature specific subclass, describes a resource state transition gherkin:Scenario ~ >> describes a success/failure scenario gherkin:Given ~ precondition about the old resource state, which can be used to >> show/hide a hydra:Link, which supports the transition gherkin:When ~ transition description, can be used to describe >> hydra:method and hydra:expects gherkin:Then ~ new resource state, can be used to describe hydra:returns and >> hydra:statusCodes >> >> I think if the descriptions would be annotated with metadata it would be possible to generate a REST API and a >> documentation based on the integration tests of the application. Ofc. the current form of cucumber does not support that, >> but the feature descriptions contain a lot of info about what the application does and the step definitions provide a lot of >> code which could be reused by writing a REST adapter. >> >> What's your opinion? >
Received on Wednesday, 27 May 2015 06:21:19 UTC