This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # babashka (66)
- # beginners (37)
- # calva (3)
- # cljdoc (2)
- # clojure (14)
- # clojure-australia (6)
- # clojure-doc (4)
- # clojure-europe (22)
- # clojurescript (9)
- # datalevin (5)
- # datomic (4)
- # emacs (5)
- # events (1)
- # figwheel-main (6)
- # graalvm (41)
- # lsp (16)
- # luminus (1)
- # off-topic (2)
- # overtone (2)
- # re-frame (2)
- # reagent (8)
- # remote-jobs (1)
- # reveal (49)
- # shadow-cljs (9)
- # spacemacs (14)
- # tools-build (4)
- # tools-deps (16)
Curious about how people think individual test assertions should be displayed. Test var results are shown in the first screenshot. If any assertion in the test var fails, it is marked with a yellow fail marker. Each test var runs many test assertions though. Each test assertion can succeed or fail. The test assertions do not have an identity like the test var they reside in. Cursive's test integration will show the output in a text like view (screenshot 2). Each test assertion failure is separated by some space. I can do that too. I could see that layout getting a bit overwhelming for cases where one test var has lots of test assertions.
I was thinking an alternative view would be to add 1 more layer to the tree view. Under each test var, I show the assert-expr dispatch value (e.g.,
=) and line number. These would not be named since there's no identifier for them. For example, tree view would look like this:
I might even be able to open files in IntelliJ by clicking a link in. a stacktrace or line number! https://www.jetbrains.com/help/idea/opening-files-from-command-line.html
Agreed! Thoughts on how someone might configure something like that in the case they're not using Cursive?
re showing assertions: I'd go with clojure.test reporting semantics, e.g. not showing the assert-expr, but by default showing counters instead.
The thing I worry about with the layout Cursive shows is near impossible usability when testing output gets large. That text area used would be absolutely massive.
I do agree that it departs from native reporting semantics, which I don't particularly like. Maybe there's some middle ground like collapsible sections in the text area thing.
my worry here is that this tree might also get pretty huge if we have something like this:
(dotimes [_ 1000] (is ...)))
re open in text editor/IDE — I imagine a preference key that allows specifying some well-known editors, maybe with automatic inference to see if vscode/intellij is installed, maybe with option to provide a command string with substitutable places. Maybe it can be available as an action on vars/nses and things resolvable to vars/nses.
In our case, yes. We deal with very large data structures. That's a great point. We also have some test vars with 10s of thousands of asserts 😅 (generated from data, akin to gen tests).
What about Cursive's output style (test tree left & assertion view right) where the assertion view has collapsible sections?
What component do you suggest I use? I see the accordion but only being able to open 1 section seems super limiting...
re Cursive's output style — I think it won't work for reveal, mainly because reveal is usually in "portrait mode", e.g. bigger in vertical direction
so generally it's "cheaper" to align stuff vertically in reveal instead of horizontally
re testing context: Cursive does not include them in the test results tree view. I can easily include it, but I wonder if there was a reason he chose not to :thinking_face:
Oh wow. TIL. Cursive ignores that nesting. Here's what it looks like when I run a test like that.
Man, that testing-vars thing really messes stuff up. Gotta support it, but it adds some constraints. For example, before I was able to render all the tests that would run upfront. But now, I don't have a guarantee that the vars passed in represent the actual tests that will run. Basically, everything that was keyed by var can no longer be keyed by var 😢
(Cursive does this too -- dynamically adding tree items as they get discovered in test execution)
Is there a way to adjust the size ratio of the output and result panels? I tried to drag the dividing line, but it doesn't seem to work like that.
I wanted to make default sizes as good as possible so there will be no need for tinkering with sizes
Makes sense. Perhaps there's some special conditions that would be better suited with specialized sizes?
There are some more things in this area I'm working on right now, e.g. maximizing the window with a shortcut (`F11`), so when you need to really focus on some view, it can be as big as possible
And other thing I want to do is opening views in new windows instead of result panels. This, combined with F11 to maximize allows you to make some view take basically the whole screen.
Cool! How would you control if a view opened in a new window or not? Something like combining shift+enter?