Fork me on GitHub
#clojure-uk
<
2016-07-25
>
korny08:07:12

@paulspencerwilliams: I used to be a huge cucumber fan “back in the day”, but these days I tend to think it’s a mis-step.

korny08:07:11

I love using acceptance test to drive out real business behaviour, and they should be somewhat human readable. But the whole “let’s make the tests editable by BAs/QAs” never really worked. These days I’d get a dev (or some QAs) to write the tests, and talk through them with a BA/QA to explain and tweak them - but never expect the non-coder to make significant changes.

korny08:07:16

And given that, I’d prefer an expressive test in a real language - rspec or spock or midje, or even JUnit or clojure.test - to cucumber.

korny08:07:19

It is a bit of a hassle in clojure though, as acceptance tests (in my opinion) are fundamentally procedural - “I do X and expect Y to happen, then I do Z and expect Q to happen”. They tend to involve a lot of state, and really laziness is not something you want to handle.

dominicm09:07:44

If I understand the problem you describe, using core.async for that state is helpful. "I send X into my system, and on out I hear Y event"

paulspencerwilliams09:07:57

Sounds interesting @dominicm. Not played with it yet; wonder if that eould handle waits too...

dominicm09:07:12

@paulspencerwilliams: It has a timeout feature, if that's what you mean.

dominicm09:07:37

I found core.async to be very interesting once I realised it was designed to describe whole systems (not functional things inherently)

glenjamin09:07:14

kerodon does a decent job of letting you write scenario-based tests

thomas09:07:14

and even more amazingly you can use it on both clj and cljs.

glenjamin09:07:11

did you ever look into http://bbc.github.io/ShouldIT/ or something similar korny ?

glenjamin09:07:28

it matches test suite output against bulletpoint lists in markdown

korny09:07:10

@dominicm: ooh, very interesting idea. It’d be very cool to write a testing framework (or addon to a framework) based around core.async

glenjamin09:07:50

if anyone is a big fan, you’re welcome to adopt it

glenjamin09:07:03

i inherited it a few years ago, but I don’t really do any clojure

korny09:07:46

Actually, I tell a lie - I did look at Kerodon, I think we were using it on one of our clojure projects, I just forgot 🙂

korny09:07:43

(not a project I was on, but I helped them at a couple of points)

korny09:07:20

I think we were using it more for unit tests than BDD-style acceptance tests, but it’s a nice example of a way to do scenarios in clojure tests, definitely

glenjamin09:07:30

yeah, the actual implementation is a bit odd sometimes, but the general idea of using the threading macro with a state map for scenario tests is sound

korny09:07:32

makes sense.

korny09:07:36

I just looked at ShouldIT, and it looks nice, though as I understand it it’s mostly around turning normal test output into a nice properly structured report, rather than being a test runner

korny09:07:56

but for the output stage I could definitely see the benefits.

korny09:07:14

regarding state - I think the main benefits of using a core.async approach would be that often you are driving webdriver or some other slow back-end system, and in those cases it’d be great to use alts! style of logic, to say “either X should show on the page, or an error message”...

glenjamin09:07:09

yeah, the idea of ShouldIT AIUI is you write the “specs” in markdown with your business people

glenjamin09:07:24

and then use that list to drive creation of your automated tests

korny12:07:03

What I want: a clojure linter that detects any code of the form:

(if (blah)
   (debug “something happened”)
   (something))

korny12:07:53

where ‘debug’ is any logging message 🙂 Sigh - the number of times I’ve made this mistake. I should try to force myself to default to when - but it’s hard to break decades of habit

otfrom12:07:23

korny: not sure if kibit or eastwood would catch that

otfrom12:07:26

worth a try though

korny12:07:56

yeah - maybe I could see if I could write one and submit it as a pull request

otfrom12:07:58

using spec would if that was the return (as sometimes you'd get a nil instead of another type)

korny12:07:41

most of what I’m doing is horribly side-effecty. Actually most code that is strewn with log messages is usually side-effecty. (as are the log messages themselves)

korny12:07:02

… so the (something) has no meaningful return value quite often

otfrom12:07:57

that does make it trickier

otfrom12:07:17

are you able to segregate your side effecty code from your predicates and transforms?

otfrom12:07:32

that if could be a multimethod potentially

otfrom12:07:43

(obvs I have no idea what is going on in your code base)

mccraigmccraig12:07:13

@korny: break the if habit

korny12:07:54

@otfrom: Not really - the code in question is calling Java side-effecty code, which isn’t in my control, inside a Jepsen thread, which is also only loosely in my control - and it’s short-lived test code, so doesn’t warrant huge effort to make it well structured as it won’t live for more than a few months max. I think @mccraigmccraig is right, break the if habit. Actually, if I’d used kibit earlier, it would have suggested when not if before I inserted the debug statement.

otfrom14:07:36

👍 to what mccraigmccraig says.

otfrom14:07:43

and sounds like you know the code base

glenjamin14:07:33

korny: you could make your debug thing into a macro/fn that takes a second argument

dominicm14:07:32

^ this is a really good option, and does exist

dominicm15:07:29

https://github.com/georgejahad/debug-repl this is also cool. and I like it a lot.

korny16:07:41

debug-repl is neat.

korny16:07:09

Jepsen uses clojure.tools.logging, which does include a spy macro for in-line logging of intermediate results.