Fork me on GitHub
#test-check
<
2020-01-04
>
bartuka16:01:25

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

bartuka16:01:03

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

gfredericks17:01:28

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

gfredericks17:01:10

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

bartuka18:01:46

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)))

bartuka18:01:12

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

gfredericks18:01:59

you're checking the wrong return key

gfredericks18:01:06

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

gfredericks18:01:31

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#)))

gfredericks18:01:49

or maybe midje has a less hacky way to do that

bartuka19:01:15

oh.. didn't know!! thanks

gfredericks19:01:33

the keys are a bit confusingly named for legacy reasons

gfredericks19:01:24

but they're described in the docstring at least

bartuka19:01:50

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

gfredericks19:01:10

no it'll be an actual exception object

gfredericks19:01:26

:pass? is always a boolean

bartuka19:01:28

got it! thanks for the hint

👍 4
bartuka19:01:18

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

bartuka19:01:40

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

bartuka19:01:00

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)

gfredericks19:01:27

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

parrot 4
gfredericks19:01:45

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

gfredericks19:01:22

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

bartuka19:01:34

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

bartuka19:01:59

this subject has people with very very strong opinions hehehe

bartuka19:01:43

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

bartuka19:01:44

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

bartuka19:01:14

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

gfredericks19:01:26

there's language-agnostic material on that subject

gfredericks19:01:44

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

bartuka19:01:09

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

Alex Miller (Clojure team)19:01:59

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

bartuka19:01:20

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

bartuka20:01:53

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
It is a simple code to add business days taking into account Brazilian holidays to an java.util.Date. But the generator is creating java.util.Date with any values for min,secs and millis. Then, this happened:
(.equals #inst "1980-02-02T00:01:01.000-00:00" #inst "1980-02-02T01:00:01.000-00:00")

bartuka20:01:08

I edit.. both were the same, year, month and day. But different hour.

bartuka20:01:07

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

bartuka20:01:29

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

bartuka20:01:45

but some day this extension happened without proper care rsrs

gfredericks20:01:30

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

bartuka20:01:25

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

bartuka20:01:31

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