Clojurians Log v2

@iagwanderson has joined the channel

hi ppl, how do you usually integrate test.check with deftesting or midje?

I am slowly building some property-based tests in my code base to learn more about it, but I currently use midjeto my tests and would like to have it more integrated

At worst you can call the quickcheck function and assert that the pass? key (or whatever it's called) is true

defspec is the normal integration point with clojure.test, I have no idea if that's usable with midje

I had done this macro to help me... it's working but not ideal

(defmacro check-that [desc n property]
  `(fact ~desc
     (let [check# (tc/quick-check ~n ~property)
           passed# (:result check#)]
       (when-not passed# (clojure.pprint/pprint check#))
       passed# => true)))

the message when error occur is not visible in the midje stack trace.. but I still get it.

you're checking the wrong return key

exceptions are exactly the edge case where that doesn't work

you want the :pass? key: https://github.com/clojure/test.check/blob/master/src/main/clojure/clojure/test/check.cljc#L108

if you want exceptions reported the way midje would, you can also do something like

(when (and (not (:pass? check#)) (:result check#))
  (throw (:result check#)))

or maybe midje has a less hacky way to do that

oh.. didn't know!! thanks

the keys are a bit confusingly named for legacy reasons

but they're described in the docstring at least

the :result key is not a boolean? So when an exception happen the result will be a keyword :exception something like that?

no it'll be an actual exception object

:pass? is always a boolean

got it! thanks for the hint

just watched your presentation and started to write tests to a utils namespace I have in my current project

interesting bits already pop out!! some edge cases dealing with dates 😃

and a performance issue as well. lol. The prod version of the code took 12secs to run 1000 times.. after some refactor it went down to 2sec. And it still works! I used to slow one to validate the fast impl. (Y)

oh yeah, I love the before-and-after refactoring check

"test.check as incentive to make your code faster" is an angle I hadn't considered before 🙂

it's almost the opposite of the TDD people that put high effort into making the tests extremely fast

that's true. I stumbled in test.check because I am really studying tests as a whole subject and experimenting it in my project here

this subject has people with very very strong opinions hehehe

saw some guy arguing that Golang was the standard language for TDD because of the incredible fast feedback you get from your entire suite running in ms

o.O

¯\(ツ)/¯

do you have more material about property-based tests to share? I am looking for something more conceptual about how to spot invariants

I know it is very context based, but some general concepts must be applicable

there's language-agnostic material on that subject

or rather, any material on that subject regardless of language would be applicable

e.g., a quick trip in the googlemobile suggested: https://fsharpforfunandprofit.com/posts/property-based-testing-2/

cool, thanks! I will keep my search as well o/

I spent a bit of time trying to talk about this in Clojure Applied, not sure I said anything revolutionary, but perhaps of interest

I like when ppl suggest a book and I have it hehe. thanks for pointing out @alexmiller Part III on Practices (Y)

yeah, it's chapter 8

gosh, how can I work next monday o.O I just got this error from a test:

There is insufficient memory for the Java Runtime Environment to continue.
 repl_1  | # Native memory allocation (malloc) failed to allocate 312 bytes for AllocateHeap
 repl_1  | # An error report file with more information is saved as:
 repl_1  | # /app/hs_err_pid46.log

(.equals #inst "1980-02-02T00:01:01.000-00:00" #inst "1980-02-02T01:00:01.000-00:00")

it was suppose to be true in the prod code =(

... why?

people [me probably] was imagining this code as a Date not DateTime inputs

but some day this extension happened without proper care rsrs

LocalDate?

yes

so many languages/libraries seem to encourage people to think of datetimes as localdates with more resolution, but that's not at all the case

yeah, first few minutes and a lot of lessons. This year will be nice. haha

and funny enough, we had an example-based tests.. but the java.util.date passed around was all with T01:00:01.000-00:00