Generative testing is great but defining the contract gets more complex the further away from a 'unit' you get. It is easy to define extensive generators for (defn length [s]). It is a much bigger problem to generate extensive inputs for every call-site of (length) and then every call-site of the call-site of (length) and so on.
This is not a problem limited to clojure.spec, it is a limitation to any example based testing, and in that sense, a helpful simplifying lie is to think of generative testing as example based testing on steroids. Type systems work across the code base as a whole and are therefore (in another helpful simplifying lie) more extensive. The other consideration is that type systems limit the 'specifications' you can give it, clojure.spec specifications can be as rich as your code and are therefore unbounded. Don't get me wrong, I am just starting to get into clojure.spec and I too am very excited, but given the specs are effectively unbounded, it isn't going to catch all the errors that types are. However, BECAUSE it is unbounded it can be far more powerful. Just my 2p (and I haven't had any coffee yet so the above might be complete drivel). On 22 October 2016 at 02:00, Daniel <doubleagen...@gmail.com> wrote: >> In this sort of situation, a static type system which provides universal >> guarantees (this value can never be null) is more useful than a contract >> system (no null values have been seen yet for the test inputs you've tried). >> There's simply no way I can test all combinations, or reproduce all >> combinations that users might have running. > > Isn't a major selling point of generative testing to create loads of unique > cases you can't invent on your own? > > You don't trust it to do that? Is that from personal experience? Genuinely > curious because I am a little excited about using it in a project at work but > this is disheartening. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
