morning

Hullo

Morning.

Moning

@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.

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.

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.

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.

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"

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

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

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

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

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

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

it matches test suite output against bulletpoint lists in markdown

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

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

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

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 🙂

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

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

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

makes sense.

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

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

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”...

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

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

ftrnn

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

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

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

korny: not sure if kibit or eastwood would catch that

worth a try though

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

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

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)

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

that does make it trickier

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

that if could be a multimethod potentially

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

@korny: break the if habit

@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.

👍 to what mccraigmccraig says.

and sounds like you know the code base

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

^ this is a really good option, and does exist

https://github.com/clojure/tools.trace/ covers a lot of things

https://github.com/dgrnbrg/spyscope this covers your type of usage

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

debug-repl is neat.

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