[ANN] prismatic/schema 1.0 adds automatic test data generation

[Jason Wolfe]

We're excited to finally bring Schema out of alpha, while introducing some new exciting features around testing: test.check integration and data completion.  Check out the blog post for details about these new applications.

http://blog.getprismatic.com/schema-1-0-released/

We've also rewritten the internals of schema for this release, to make it easier and faster to add new schema types and applications.  We expect ordinary users of Schema should see no breaking changes, but custom schema types or tooling will likely need to be updated.  Please see the changelog for details.

https://github.com/Prismatic/schema/blob/master/CHANGELOG.md

Comments and suggestions welcome!

[Matt Mitchell]

Awesome and good work! Can't wait to try it out.

- Matt

[Jason Felice]

I have a question:  "both" is deprecated with a note to use "s/conditional" instead.  However, that doesn't work for my case.

I have the following: (s/both s/Int (s/pred pos?))

If I rewrite it to (s/conditional pos? s/Int), this throws:

(s/check (s/conditional pos? s/Int) "")

Since (as far as I can tell), I can't verify the type is numeric before applying pos?

I could do this: (s/conditional number? (s/pred pos?)), but I'm going to guess this will defeat test.check support, which I'd like to use.

Thoughts?

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matt Mitchell]

I just created a scratch project using schema-1.0.0. Requiring schema.core works fine, but coerce throws an exception. Here's the repl session:

user=> (require '[schema.core])

 

nil

user=> (require '[schema.coerce])


 

CompilerException java.lang.RuntimeException: No such var: s/spec, compiling:(schema/coerce.clj:31:28)

- Matt

On Tuesday, September 1, 2015 at 2:02:30 PM UTC-4, Jason Wolfe wrote:

[Jason Wolfe]

Hi Matt, 

Thanks for the report.  

I just tried and I'm unable to reproduce.  Can you please open an issue on the schema github project with your project.clj and the results of `lein deps :tree` and we'll look into it ASAP?  

Thanks,

Jason

[Jason Wolfe]

Hi Jason,

That's a great question, thanks.  

The exception you point out is just a bug: https://github.com/Prismatic/schema/issues/263.  Preconditions currently wrap exceptions and return sensible validation errors, we just missed this in guards.  Will address this ASAP and cut a new release.  

Outside of that, I can still potentially see the desire to specify postconditions rather than preconditions (you'd rather see an error (not (integer? "1")) than (throws? (odd? "1")), which will be the behavior when the bug is fixed.  We're thinking about whether it's worth the extra complexity to support that, what are your thoughts?  If you think it would be valuable, please open another issue on github so we can track it -- thanks.

As for your solution (s/conditional number? (s/pred pos?)), that will also work fine, and you can still use the generator support -- you will just have to pass in a leaf generator for your schema (although this admittedly isn't ideal).  

Thanks,

Jason

[Jason Felice]

On Wed, Sep 2, 2015 at 9:56 PM, Jason Wolfe <ja...@w01fe.com> wrote:

Outside of that, I can still potentially see the desire to specify postconditions rather than preconditions (you'd rather see an error (not (integer? "1")) than (throws? (odd? "1")), which will be the behavior when the bug is fixed.  We're thinking about whether it's worth the extra complexity to support that, what are your thoughts?  If you think it would be valuable, please open another issue on github so we can track it -- thanks.

Postconditions are what I reached for intuitively, and so I suspect many other people will also try to figure them out.  It "feels good" if one is anticipating a generator and knows about gen/such-that, for example.

I haven't looked at the Schema generation API yet, but I'd like to not need to specify leaf generators (except perhaps for performance reasons).

That said, s/both is both (ha!) awkwardly named (since it can take more than two) and not a mechanism I'm attached to.  Perhaps there's another way?  I'd be happy if there is a concise, recommended, well-documented way, even if (like gen/bind) I have to jump through a few mental hoops to figure out how to phrase it.

-Jason

[Jason Wolfe]

FYI -- we just released Schema 1.0.2, which adds `s/constrained` for postconditions. 

-Jason

[Jason Felice]

Thanks!

I'll try it out this week and let you know.

--

[Jason Felice]

It works great.  All I did was updated project.clj, replaced s/both with s/constrained and removed the s/pred around the arguments, and it all worked.

One little weird thing: It now complains:

WARNING: atom already refers to: #'clojure.core/atom in namespace: schema.core, being replaced by: #'schema.core/atom

But I can't figure out why, because schema.core is clearly excluding atom.  This project is on clojure 1.7.0.

-Jason

[Jason Wolfe]

Thanks!  

Just fixed the warning, will go out with the next release.

-Jason

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/jfQ6vzg8pAE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.