Fork me on GitHub

We have an ID value that uses a luhn check digit. The error was being caused by line 27 - where it is using subs, it was using drop-last which ended up returning the sequence of characters


Is the expected behaviour to see what spec failed? e.g., hone in on luhn-check-digit being the failing fdef?


What is regex-spec?


Seems like that would be the problem to me.


ah sorry I missed including that. It is...

(defmacro regex-spec
  `(s/with-gen (s/and string? #(re-matches ~regex %))
     #(gen'/string-from-regex ~regex)))


I do find that there are quite a few exception messages that could be a little more helpful. For example, right now I'm hunting down a problem with a misbehaving generator, and all I have to go off of is

Execution error (ExceptionInfo) at clojure.test.check.generators/such-that-helper (generators.cljc:320).
Couldn't satisfy such-that predicate after 100 tries.


It's made a little more manageable through workflow (e.g., I know what spec I'm working on), but it would still be very helpful to get more details on what went wrong to help debugging


(That's a general spec/test.check comment, not so much orchestra)


I feel like you have a lot going on there, so it's not quite a minimal repro case at all.


To figure out the source of that string sequence issue, keep removing code until the issue goes away. 🙂 If it goes away, add that code back and remove some other code until it goes away again. Keep repeating until the only code left is necessary for the reproduction.


Namely, that spec error likely has nothing to do with generators or your custom macros or even all of that business logic around luhn digits.


As mentioned earlier - I already fixed the actual issue with the code, my question is more about debugging flow and finding the culprit. In this case the error I was getting back was not very helpful in narrowing down where to look, and I was wondering if there was something I was doing wrong to impact that.


Oh, that's my mistake. I came in last and must've missed that. I think the one thing I'd say we should keep in mind is that specs themselves should be simple enough to not really need debugging. To me, specs are for debugging, so it's awful to need to debug the debugging code. If you're stuck on weird issues with your specs, perhaps your approach can be simplified.


Note, I also never use generators, since Orchestra + good unit and functional test coverage is everything I care about. However, especially given that this functionality (ret + fn instrumentation) has been removed from Clojure core and a lot of the spec press has been around generative testing, I may not be among the majority.

👍 4

We're still fairly fresh with it - we have one other clojure project in our repos but it is pre-spec. The generative testing has been useful so far, it's already caught a few issues that we probably wouldn't have spotted with our usual approach. But yeah.. it's definitely tricky going at times with more complex specs, especially for relatively new clojure devs like myself


We have thousands of lines of specs and hundreds of spec'd functions in our code (at my company). I don't recall the last time I spent a noticeable amount of time debugging an issue with one of my specs. This is likely because they're all very simple. "This thing requires these keys. This is a number, this is a non-blank string, this matches this regex." Not too much more than that, for our entire front-end and back-end.


The bulk of ours are like that and haven't given us any issue. Todays fun was caused by the more complicated spec for the luhned ID, and some specs defining incoming requests on our API that have some internal consistency properties


Thanks for taking a look! I appreciate it. Orchestra was a great find for us, having the :ret and :fn checking on instrument is really simplifying our workflow


I'm happy you're enjoying it. 🙂


We were wondering why that wasn't part of the standard instrument


It seems like a natural thing to do


It was and then it was removed. My understanding is that the Clojure team didn't like to emphasize that usage of spec and noted the performance implications. To me, that is the usage of spec and the performance implications are negligible compared to the safety benefits.


I wouldn't want to misrepresent them and I haven't actually spoken with them about it. Would love to sit down with Rich and talk it out, but who wouldn't love to sit down with Rich and talk anyway?


Interesting. Yeah, no kidding! Definitely a brain to pick


It's because instrument is for checking calls pass the right data -- the :args key -- and check is for checking the functions themselves behave correctly (given conforming :args, does the output of the function satisfy :ret and :fn).


Orchestra complects those two, very different, types of checks.


(which is fine as long as folks understand that is what's going on and they are comfortable making that choice to go against how spec is designed)


There's the official opinion. 🙂 Thanks, Sean. Fortunately, people now have the choice.


I wouldn't say "official", coming from me -- I'm just repeating what I understand the Cognitect folks to have said about function specs 🙂


ret specs are probably going to change a lot in spec 2 as well


Hopefully not in a way which is incompatible with this form of instrumentation, I hope, Alex.


Either upstream or via a soft fork such as Orchestra.


@jeaye At work we have a branch of our code running on Spec2 -- there were several substantive changes (beside the "obvious" renaming of namespaces in :require clauses). They weren't big changes, but they were breaking changes.


Good to know, Sean. Thanks for the info.


I'll wait and see how things are, when the dust settles. The libs, spec and spec2, aren't so large as to be very difficult to either work into this case or replace with something which does. There's superb thought work going into spec2, no doubt, and I have no interest in competing with that. I just want to make sure my team and other Orchestra users will be able to take advantage of the new spec features along with the instrumentation.


Clojure 1.10.0
user=> (require '[clojure.spec.alpha :as s])
user=> (s/def ::foo :bar/this)
Syntax error compiling at (REPL:1:1).
Unable to resolve spec: :bar/this
user=> (s/def ::foo (s/keys :req-un [:bar/this]))
user=> (s/def ::foo (s/keys :req [:bar/this]))
Could someone offer a good way of thinking about the above ^^^? I.e. it is possible to refer to 'non-existent' spec inside map spec (through keys) but it's not possible at the "top level" s/def. I guess my confusion is coming from the fact that semantically those uses seem equivalent to me--both use ns-qualified keyword as a way to refer to spec--one fails the other doesn't.


Aliased specs are not as delayed as they should be in this case, which is a known issue. I have been working on fixing it in spec 2.


Amazing, thanks @alexmiller mario-star