-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DSL vs generating ExUnit directly #1
Comments
FWIW, it would be nice if one could approach a flow like this:
I suppose that compiling the spec into tests could be handled by the file watcher if you use Phoenix, but you might just as well be doing "clean" Plug code if you're developing an API :) How about having an interface similar to ExUnit.DocTest, where you just use a macro to point to the .yml source, and the tests will be generated at compile time when you run |
I had originally done a DSL (https://github.com/coryodaniel/apocryphal/tree/sly-dsl) and then tore it all up and went with bare ExUnit because it seems more clear (less macros)... Want to peek at the DSL branch and let me know what you think? |
Well, for me personally.. I'd just rather not see, or have, any code in my code base that's just generated strictly off of a spec.. The spec is the test code in this case, just like the docs are the tests for DocTests; they don't generate code that's sitting around in your repo. I don't know where you are on this, though.. it's perfectly fine to have a different opinion, of course ;) At work we're looking at possibly implementing a couple of small, internal APIs using Elixir. I'd love to play around with running Swagger specs as "acceptance tests" for these things. So I may have more specific ideas / suggestions / questions when we get to that :) |
Note, of the two options.. DSL vs. plain ExUnit.. I do like the plain ExUnit version better :) |
The text was updated successfully, but these errors were encountered: