Clojurians
#cljs-dev
<
2016-08-17
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

anmonteiro12:08:22

@dnolen: even though test.check is added to the pom.xml and project.clj it hasn’t been added to script/bootstrap which results in test.check not being available in the classpath

dnolen12:08:30

@anmonteiro: ah right

anmonteiro12:08:57

@dnolen: should make your job easier ^

anmonteiro13:08:02

@dnolen: I wonder if it’s OK to introduce test.check as a dependency for running CLJS tests

anmonteiro13:08:24

this came up because I was working on http://dev.clojure.org/jira/browse/CLJS-1754 and wanted to provide a test

anmonteiro13:08:42

but it would introduce the new dependency of requiring clojure.test.check.generators in the tests

anmonteiro13:08:33

the fix for that one is simple enough that I can provide a patch without a test, in case we don’t want to introduce the new dep

dnolen14:08:07

@anmonteiro: it’s fine to include it as a test dependency yes

anmonteiro14:08:25

problem is including that in the self-parity

anmonteiro14:08:33

not sure how to load test.check there

anmonteiro14:08:01

@dnolen: adding this as a test dep paves the way for eventual generative tests in the CLJS codebase :slightly_smiling_face:

mfikes14:08:30

I’ll help @anmonteiro sort out how to include that dep with the self-parity test

anmonteiro14:08:14

@dnolen: running the self parity tests for this will need an updated script/bootstrap script, should I create a ticket for updating that one as well?

dnolen14:08:29

@anmonteiro: go for it

mfikes14:08:29

Perhaps the groundwork for this could ultimately lead to the ability to employ generative tests in the ClojureScript test suite itself. (http://dev.clojure.org/jira/browse/TCHECK-105 is pending and would make test.check fully usable from self-hosted ClojureScript, covering all bases.)

dnolen15:08:06

would definitely like to see generative tests added to ClojureScript a la Clojure

anmonteiro15:08:42

@dnolen: why cljs.spec.impl.genand not cljs.spec.gen ?

anmonteiro15:08:37

I know there’s an issue in JIRA for a special case alias, but the actual doubt I have is if it’s not possible to mimic Clojure namespaces for this one?

dnolen15:08:58

@anmonteiro: because Closure namespaces can have clashes due to being represented as JS objects

dnolen15:08:14

i.e. cljs.spec/gen var clashes with cljs.spec.gen the namespace

anmonteiro15:08:21

makes sense, but sounds annoying

dnolen15:08:14

but also I haven’t heard why people need to access this ns typically

dnolen15:08:20

maybe I missed a good reason

anmonteiro15:08:34

I can’t argue with you on that, as I haven’t needed to require that one yet, except for the boolean? patch test

dnolen15:08:14

so until people need it, I think handling it isn’t really that important

anmonteiro15:08:41

I agree, was just curious about the justification for the difference in naming between CLJ and CLJS

dnolen16:08:50

yeah clashes are a real problem

dnolen16:08:05

we do have code to detect it since it’s a pretty common issue

anmonteiro16:08:17

ah awesome, could you point me to an example of that in the codebase?