This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (3)
- # beginners (89)
- # boot (198)
- # cbus (4)
- # cider (11)
- # clara (2)
- # cljs-dev (27)
- # cljsrn (4)
- # clojure (141)
- # clojure-austin (4)
- # clojure-italy (11)
- # clojure-nl (1)
- # clojure-poland (2)
- # clojure-russia (35)
- # clojure-spec (33)
- # clojure-uk (55)
- # clojurescript (111)
- # core-logic (15)
- # cursive (2)
- # datascript (47)
- # datomic (132)
- # emacs (4)
- # jobs (1)
- # lein-figwheel (13)
- # leiningen (15)
- # lumo (20)
- # off-topic (110)
- # om (8)
- # onyx (20)
- # parinfer (2)
- # protorepl (1)
- # re-frame (36)
- # reagent (5)
- # remote-jobs (1)
- # ring (2)
- # ring-swagger (5)
- # specter (6)
- # uncomplicate (3)
- # unrepl (77)
@alexmiller @gfredericks I'd listen about "highjacking" specs with generators, and generators strategies in general, e.g. for cases, where you need to define some root rules, and all downstream generators need to inherit it.
Which is, probably, the same issue/situation, as "I wrote a lib, and need to either hardcode some resource to use it implicitly (bad, but easy), or need every function to accept it as an argument (good, but
messy verbose)". Think
taxi-driver's browser arg,
One use case would be testing datomic/datascript, where on the one hand you have all the specs about
db/`tx-report` structure, but on the other, when you test actual transaction, – an extra layer of testing the data flow is required, like "my temp ids appear in tx-report, and transacted data appears in db". Such "flow" specs can be described, and tested generatively, but it is somewhat messy, and is hard to keep de-complected from "structure" specs.
@misha is this a situation where you're doing a higher level test and want to model some external system?
the closest to real life I got – is datascript testing, which I described. It probably is "higher level testing" from some pov, but feels like essential for any lib a larger than few util functions
You might perceive datascript as being external to the app code, yes. Not sure if I answered your question
ok, how'd you go about testing datscript/datomic's
I'd have specs for db, tx-report.
I'd see, if structure conforms the specs.
But then I'd need to test that, all temp-ids are permanent, that mapped temp-ids - are the same and for same entities, as in submitted data.
That extra data in new db - is in fact submitted data.
I feel, like it can be done on "generators" level, and not in just custom test code, which does not leverage, say, spec.
Because after I'm done testing datascript, I want to model it (lol now I understand your question ) to enable testing app code build on top of it, and I would not be able to do this with custom test code, which does not leverage generators
@misha so when you say "custom test code" you're thinking of example-based tests, not something like vanilla test.check properties?
I think the question can be narrowed down to "how to use system-wide seed data, and set of rules, which affect all(most) of the generators"
I don't have an intuition developed in this area much, so I might be talking gibberish here and there. That's why I'd listen to something structured on the topic
yeah, it sounds like you need a higher level overview; which is somewhat at odds with alex's more focused talk idea, but it might be that going over certain generator patterns would illuminate other aspects as a side effect
anything helps, and generative testing is so huge, but "under-appreciated" from talks perspective. Everyone's just "here, you can generate strings, ints, and booleans. Boom! Off you go."
@gfredericks check this out, interesting approach to closures, to solve what I was trying to describe earlier today: https://clojurians.slack.com/archives/C03S1KBA2/p1501187926443798
more on this in this thread https://clojurians.slack.com/archives/C03S1KBA2/p1501179951981871?thread_ts=1501070045.404030&cid=C03S1KBA2
@gfredericks no, but this might be useful in a highjacking generators with seed data. Seemed relevant to what I wrote earlier today...
I had a problem with my spec usage, where I wanted to have a spec for, say datascript entity. This spec contains datascript id spec, which can specify either id-before-transaction (actual id or temp id), or id-after-transaction (actual id only). So I have this nested spec, at the bottom of which there is an id-spec. For some tests I wanted that id-spec to be id-before-transaction, and for the others – id-after-transaction.
ok I can't find a gif to demonstrate it. but imo that sounds like a sign that you have two different things that should have different names
@bfabry that's sort of true, but I doubt, that redefining entire entity spec with only id spec change – is THE solution.
datascript-core spec and then have
datascript-after-transaction for the three cases where you 1) don't care, 2 & 3) do care.
(or possibly you only need
transacted-datascript since the ID in the first one is either anyway)
Given that you have two ID specs, presumably there are situations where you care which type of ID you have?
@seancorfield in this example, you are might be 100% right. But I just want to illustrate a situation, where you might have a composed spec more than 2 levels deep, and you want to replace a leaf sub-spec or a generator for it.