What event does one use at the end of all tests in clojure.test for report?

defmethod clojure.test/report :summary

I’m trying to debug a NoClassDefFoundError when instantiating a Java class. Here’s my situation: I am using deps.edn to load in an artifact from a private Maven repository (my company’s Nexus mirror). I can spin up a REPL (using CIDER) and (import) the class I need from the artifact just fine, but if I actually try to instantiate it I get a NoClassDefFoundError. I’m not sure how to go about debugging this or what next steps to take.

Is it possible to elucidate what the repl is actually doing through JVM logging?

I am trying to teach Clojure and show what the repl is actually doing ... otherwise the fact that you are redefining code in process get slost

I was hoping that the JVM might spit something out on a class reload if you switched on some flag but googling is yielding nothing ...

I think chouser has a ticket on jira where he has clojure emit when it is reloading or adding classes to demonstrate a bug. But i can't imagine any info like this would benefit a beginner

you could use -verbose:class flag, although not sure if that’s helping you at all

a lot of the interesting bits are happening in Clojure’s DynamicClassLoader though, not at JVM level

Thanks @dpsutton they are not all beginners, some have been taught in Java and used Clojure without thinking too deeply about it ...

Thanks @alexmiller is that a flag on clj ... or a java flag ??

Looks like its java ... https://stackoverflow.com/questions/10230279/java-verbose-class-loading

java

I'll try that thanks 🙂

to use with clj: clj -J-verbose:class

it seems that Java Reflection has some limitations when it comes to generics. I wonder, is there an alternative way in clojure to call a java method dynamically (i.e. I have the method name as a string)?

my problem is that I can't get the Method object properly with Class.getMethod(...) because I don't have the actual class, but Object, since it comes from a type parameter

what do people use these days for testing? I was looking at speclj but it seems its not active

clojure.test is the most used by far

I use standard clojure.test - simple and readable, with no macro hackery involved.

clojure.test is standard and readable, but it for sure is macro land

I was referring to midje levels of macro hackery.

haven't looked into that but i hear it s complicated

so fair point 🙂

Is there an easy way to have clojure.pprint/pprint print newlines in strings as a new line? i.e. Instead of this:

(clojure.pprint/pprint {:text "asd\nasd"})
{:text "asd\nasd"}

(clojure.pprint/pprint {:text "asd\nasd"})
{:text "asd
        asd"}

that's a newline plus a bunch of spaces

you could override print-method for String to do that maybe(?)

@kenny

I was running some generative tests and ended up seem this behavior:

(= ##NaN ##NaN)
=> false

is this expected?

yes, that's described by the floating point spec

I only want to do that for particular prints, not all. Is there a way to bind it temporarily?

thanks guys

there's some amusing corner cases

user=> (conj #{##NaN} ##NaN ##NaN ##NaN)
#{##NaN ##NaN}

Now that's interesting. Any idea why that occurs?

it has to do with when and how the set is checked for the value being present - I forget the details though

it's possible to end up with three or more NaN in one set as well

I tried adding a couple more NaNs and couldn't get 3 🙂

yeah, it's more elaborate, trying to recreate...

user=> (into #{} [##NaN ##NaN ##NaN ##NaN ##NaN])
#{##NaN ##NaN ##NaN ##NaN ##NaN}
user=> 

NaN's are a huge pain when generative testing

to the point where I have written tests that say something like (or (= a b) (.contains (pr-str a) "##NaN"))

Haha yeah I've struggle with that one too. I think I ended up doing a postwalk, replacing ##NaN with :nan then doing the equality check. Not very efficient though...

There are many other things that generative testing could choose to generate that would cause things to not always be = when you wish they were, e.g. mutable Java collections nested inside of Clojure sets or as map keys, regexes that look the same but are non-identical objects, and a handful of others. I have an article that lists all of the gotchas I know about for Clojure/Java equals here: https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/equality.md

It sounds like the default spec generators don't generate those other things, but they do ##NaN

Seems like it would be worth having a spec generator that by default did not generate those.

I don't know of any way to "vote" on Github PR's, but I am hoping that article becomes a guide on http://clojure.org some day: https://github.com/clojure/clojure-site/pull/267

> There are many other things that generative testing could choose to generate that would cause things to not always be = when you wish they were I wonder if this is part of the rationale behind 1.10's clojure.datafy.

no

how do peope that use clojure.test verify their mocks, bdd style? @noisesmith @sgerguri @dpsutton