This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (2)
- # beginners (36)
- # boot (37)
- # cider (65)
- # cljsrn (92)
- # clojars (3)
- # clojure (225)
- # clojure-austin (5)
- # clojure-belgium (2)
- # clojure-brasil (3)
- # clojure-china (1)
- # clojure-greece (2)
- # clojure-mexico (3)
- # clojure-news (2)
- # clojure-quebec (1)
- # clojure-russia (14)
- # clojure-spec (24)
- # clojure-uk (53)
- # clojurescript (34)
- # cursive (14)
- # datascript (9)
- # datomic (4)
- # defnpodcast (8)
- # devcards (30)
- # dirac (7)
- # editors (7)
- # emacs (1)
- # figwheel (1)
- # hoplon (85)
- # immutant (2)
- # incanter (1)
- # luminus (5)
- # off-topic (41)
- # om (18)
- # onyx (11)
- # perun (2)
- # re-frame (11)
- # reagent (9)
- # ring (3)
- # spacemacs (2)
- # spirituality-ethics (1)
- # test-check (19)
- # testing (12)
- # untangled (14)
- # yada (9)
@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...
I found core.async to be very interesting once I realised it was designed to describe whole systems (not functional things inherently)
@dominicm: ooh, very interesting idea. It’d be very cool to write a testing framework (or addon to a framework) based around core.async
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 :slightly_smiling_face:
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
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
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
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 :slightly_smiling_face: 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
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)
@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
Actually, if I’d used kibit earlier, it would have suggested
if before I inserted the debug statement.
korny: you could make your debug thing into a macro/fn that takes a second argument