I got used to Clojure's stack traces rather quickly. But I also read source code for fun.

clickabe clojure stacktraces are a must-have to me. I think that most of beguinners stuck because they don't have it.

wait @U2J4FRT2T is that a thing?

Depends on your IDE. Both Cursive and Calva offer clickable stacktraces, if I'm not mistaken.

@U2FRKM4TW Oof, yeah it's not bad for me now, but I also feel spoiled by the CL debugger (what do you mean it didn't crash and I can just change the value of an arbitrary function mid-failure and try again?)

Ah, maybe they have something similar for Cider?

Im a cursive fan. I feel that is is really hard to have cool clojure things in a IDE that don't have a good java support.

dang ;/ Maybe I should've come from a Java background first? The Clojure class I followed used cursive, but I felt kinda bombarded by all the.... everything in IDEA. (I get that it's all there for a good reason, though)

Which reminds me, is there still no good way to do android development in Clojure? Last I asked was a couple years ago, so that may very well be not true anymore!

(or is it all done through like react native or something?)

I haven't spent too much time searching around for it, but given what little I do know, React Native would definitely be my go-to thing for mobile development with Clojure.

I learned clojure before learn java. I learned java mostly from reading code, probably after click in a stacktrace. Intellij many issues, I would love to use a foss editor. I have some 5+y issues in cursive repo. But that is what we have...

I developed an app in ~2017, when shadow-cljs and fulcro didn't support RN officially. And it was awesome. JS React Native nowdays still feels more primitive than my setup. RN stacktraces are always bad, but with the right debugger and source map config, you can have it. A nice thing about RN stacktrzces is that they are clickable. But it opens in the debugger, not in the editor.

Shadow-cljs, browser console and cognitect rebl, are a nice example that nice developer tools don't need to be inside your editor.

Emacs & cider have big (comparable or worse) issues? Always seemed fine whenever I've used them, though I haven't worked on a large codebase besides ones written in python (and a Java one via meghanada).

(but I'm also a big neovim/emacs person anyway, so YMMV ofc)

Also good to know, thank you! Is that still the stack you'd recommend for RN with Clojure now? I'd love to do some development in that space

@U047X4R9ENN if you haven't run across it, https://8thlight.com/blog/connor-mendenhall/2014/09/12/clojure-stacktraces.html is a really helpful article on reading Clojure stack traces. Also a pointer to some other useful stack trace resources https://ericnormand.me/article/wrangling-clojure-stacktraces.

oh, thank you @U077BEWNQ!

Nice article from Connor Mendenhall. I have one similar too. https://souenzzo.com.br/reading-and-understanding-clojure-errors.html

most of them one way or another wraps around clojure.test 🙂 I personaly like https://github.com/hyperfiddle/rcf because it is expressive and easy to use in case of async workflows

Sadly, the greater clojure community has abandoned alternatives. Midje and Expectations were solid, and speclj had some good ideas but the tooling and repl integrations didn't grow for them like it did for clojure.test, and over time folks migrated away. I think it's pretty disappointing, but hard to challenge the built-in, even when it's pretty lacking

I still use a pre-clojure.test version of expectations everyday. It still works 🙂.

I quite like https://github.com/cognitect-labs/transcriptor, even though it’s quite idealistic with regard to preferring to test properties rather than specifics.

For completeness, https://github.com/clojure-expectations/clojure-test , while technically is clojure.test, still feels like the mentioned Expectations lib

running such tests from whatever IDE/repl/... you have with zero changes needed is just great :)

Thanks all!

We use the clojure.test-compatible Expectations very heavily at work -- we adopted the "classic" Expectations ages ago but got frustrated with it not being compatible with clojure.test tooling, which is why I wrote expectations.clojure.test and it is actively maintained. You can mix'n'match with clojure.test but it deliberately imports and exposes several utilities from clojure.test so you can use it instead of needing to require/refer parts from c.t.

Compatibility with c.t tooling is a big deal -- that's why other testing libraries have fallen out of favor: they're just a pain to work with from CIDER (Emacs, VS Code) or Cursive.

> it deliberately imports and exposes several utilities from clojure.test so you can use it instead of needing to require/refer parts from c.t. That’s reason enough for me! Your library is at the top of my Google search, so congratulations on that 😆

If you have any Qs, feel free to ask in #C08LK2DH7 or #C2L9MU2RY or via DM.

> it deliberately imports and exposes several utilities from clojure.test so you can use it instead of needing to require/refer parts from c.t. Woah, I didn't realize that. That's marvelous.

https://github.com/clojure-expectations/clojure-test/blob/develop/src/expectations/clojure/test.cljc#L564 and also use-fixtures (since it supports the cljs.test/use-fixtures features as well as clojure.test/use-fixtures)

I admit I never used a fancy test lib, but I've also never found I needed anything more from clojure.test. rcf I've also come to like just because the inline tests and the repl integration is nice.

I guess I just feel I always forget what all those additional DSL words do, whereas with is it's just all normal Clojure predicates that I always remember.

FWIW, I love #CCY2V0U6A — watch/reload works so well, great way to do notifications of test results on macOS, great handling of output, etc. And totally compatible with (or relies strictly on) Clojure.test.

Yeah, there's definitely scope for all sorts of interesting test runners -- I like that Polylith's test runner is incremental (and uses plain clojure.test under the covers -- although it can also be configured to use Kaocha so you benefit from better failure reporting etc).

I have a hot key to run "associated tests" when I'm working on a namespace: it attempts to require <current-ns>-test and then runs the tests in that ns. So my workflow is: • edit a function in the source ns • alt+enter to eval that fn; rinse and repeat • ctrl+alt+space x to run the associated tests And Portal displays the test run status (success/failure), any output from the test, and the test run summary (hash map with passed/failed/errors/total)),

When I'm working in a test ns, again I eval each test as I work on it alt+enter and then I can either run all tests in that test ns ctrl+alt+space t or just run the current test ctrl+alt+space c (Portal shows the test output).

I prefer this to the built-in CIDER-based test run stuff since I have more control over it 🙂

I think the person who wrote clojure.test mentions regretting adding it to core too quickly and not taking more time. A lesson they learned later to say "no" to more stuff so that things making it into core had more hammock time. That said, I personally like clojure.test, it's very KISS. I think the bigger issue is with the reports machinery and extending it.

Yeah, I think it would be awesome to see clojure.test spun off into a Contrib lib so it could evolve independently of "core". I've offered to maintain it, if ever that happens 🙂 I like its simplicity but I would like it to be a bit more expressive and have better failure reporting, especially on large data structure results.