Open marivb opened 9 years ago
Hi @marivb - I really appreciate the contribution!
I completely understand why you would want better ERB templating, since ERB templates was the first features I requested when I started working on Pacto.
However, I want to make sure that this happens in a way that fits into the future plans for Pacto. A lot of the open issues are related to the need for better contracts (see the contracts label on issues). I've come to the conclusion that the best way to fix those issues, and to standardize on a contract format that is complete and compatible with many other tools, is to move towards Swagger 2.0.
I plan to deprecate the "native" contracts once I have a tool to convert them to Swagger. So I don't want to add new features to the NativeContractFactory
unless they can also be added to the SwaggerContractFactory
.
I'm interested in doing templates in Swagger, but I hope to do it in a way that avoids breaking compatibility with other Swagger tools. There are other tools that can use or validate the same contracts. It would be unfortunate if you couldn't use projects like Swagger-Editor or Swagger-Tools because of the templates.
Plus, I want Swagger contracts, and even much of Pacto, to be a polyglot solution. Yes - it's a Ruby library and has the best integration for testing Ruby projects, but I'd also like it to be easy to use Pacto for non-Ruby projects, or share contracts with other (non-Ruby) Swagger tools.
In order to make that possible I've been leaning towards towards Mustache instead of ERB. Mustache is more limited (which is arguably good - complex templates could be hard to support), but it is supported across many languages. That could make it a lot easier to share templates between Pacto and other Swagger projects like Swagger-PHP, Swagger-JS, Flex (Python), etc.
I guess to move forward it would help if you answered two questions:
That makes sense.
Swagger does seem to have some interesting features and nice syntax, from what I could quickly learn. But I noticed a comment on the code about "Swagger doesn't have a clear way to capture request examples" - that would be a deal breaker for us, since we need the contracts to be executed with the examples provided... and we're also using examples in our stubbing to allow different answers to be provided, though I haven't finished that PR yet.
As to your questions:
Are your templates simple enough that you think you may be able to use Mustache instead of ERB?
We don't have crazy logic in our templates, but we do call methods such as:
Env.current[:username]
Responses.body_path('list pets', 'pets[0].id')
While the first one seems straightforward to do with Mustache, I'm not sure about the second one. The idea is to retrieve information from the response of previously executed contracts, so that our request examples can be environment and data agnostic when we're running and validating contracts. The advantage of the erb template is that we write a generic storing and retrieving Responses class and we just need to use it over and over in the contracts, but it seems to me that with mustache we'd have to write code for each bit of information we'd like to get - I didn't see a way to pass parameters in the syntax. Am I interpreting that right or did I miss something?
Where are you interested in using templates? Is it just for request/response examples?
In our use case, basically, yes. It's so that data sent when executing contracts is accepted by the services. From a quick look, it seems we also have some tags in request headers, but I'm not sure why that couldn't be in the examples section as well.
As a data point, we use JavaScript on client side and Java on server-side, only our contracts are in Ruby. Our goal is to write as little Ruby as possible, just enough to support executing and stubbing contracts, so that on a daily basis we only need to write contracts.
So that contracts/examples can have load-time variables like environment specific values.
If a file ends with .erb, compile the template when loading the contract.