Clojurians Log v2

Happy Friday the 13th! New episode out today, wherein we talk about the times we would rather not be lazy. https://clojuredesign.club/episode/088-do-dorun-run/

3rd Larry Wall virtue is impatience

@neumann or @nate do y’all have any open source examples of good fiddle files? I understand the concept but wondering what they look like “in production”

@ianjones here are a couple of examples: - https://github.com/app-sauce/fiddle-driven-development-2018-talk - source code that accompanied a talk I gave at the LA Clojure meetup. The fiddle files are in dev/fiddle, and the readme shows how to exersize them - https://github.com/jrwdunham/tegere - this is a library maintained by @jrwdunham, and you can see the fiddles in src/tegere/fiddle/ I found the second one with a github code search for fiddle, although that's mostly dominated by mentions of hyperfiddle.

That's funny. I learned the concept of fiddle files from listening to your podcast. Very helpful idea for me — thanks!

I'd be interested to hear your thoughts on the tension between tests and fiddle files (or "Rich" comments) in this context @ianjones. REPL-driven dev seems to encourage fiddling and evaluating as you build, and once you confirm that things work as you expect, testing seems unnecessary. But, in reality, sometimes tests are necessary or mandatory. So then you have to convert your fiddles to tests, and that can be inefficient. Wondering if you have strategies to mitigate this inefficiency, or if you don't really see it as a problem...

I think @nate has a way of automatically re-running tests when related files get saved, but I haven't done that yet myself.

I definitely agree that "fiddling" is for figuring out the code and testing is for pushing on the edge cases and making sure future changes don't mess stuff up!

Another example of a "topic" or "workflow" fiddle:

(comment
  ; Re-create all the EDN tables from the tables in the "stats-by-hero.csv" file
  (util/reimport-tables fiddle.stat-table/stats-file)

  ; Browse each of the stat tables to make sure they imported OK, the labels
  ; look OK, the stats are the right type, and they point to the right hero.
  (fiddle.stat-table/check-table :stat-card-6)
  (fiddle.stat-table/check-table :caster-6)
  (fiddle.stat-table/check-table :live-4)

  ; Dump out the raw data for reference. (Not terribly useful.)
  (fiddle.stat-table/dump-table :stat-card-6)
  (fiddle.stat-table/dump-table :caster-6)
  (fiddle.stat-table/dump-table :live-4)
  )

Oops, I referenced Ian when I meant to ping @nate and @neumann. Anyway, thanks for those examples and elaboration.

@neumann I use spacemacs and cider and can run a namespace's tests or a single deftest with a keyboard shortcut, so I think I get equivalent functionality to what you're describing with vim and fireplace. I too end up following a workflow (though maybe I hadn't formalized it as carefully as that) similar to what you itemized, and I've definitely been writing those kind of "topic" comments in repl/fiddle namespaces of late...

In particular, though, I've noticed that "fiddle" code does not readily lend itself to direct translation into "test" code. I've ended up in situations where I end up writing a test assertion as:

(is (->> (copied-from-fiddle-file ctx)
           run-assertions
           (every? true?)))

which is not ideal in terms of the insight into what is going wrong in run-assertions

I agree, I don't often copy code from fiddles to tests

fiddling is more about exploration, testing is about locking functionality in

I spend time in fiddles where I figure out where something is going

and once I get there, I will decide whether I need to write tests about it

and writing tests is like setting up wooden forms and pouring concrete around the implementation

nice simile 🍷

I never really understood TDD before clojure, and fiddle files have really convinced me that it's untenable

yeah, so maybe the temptation to seamlessly merge fiddle code into test code should be resisted

interesting. So any generalizations on how you decide whether something needs tests? Do you write property-based tests regularly?

yeah, just because they both exercise the code in multiple ways doesn't mean they are identical and should share implementation

if it's a smaller transform or I/O, I usually don't write tests

they can cause an inertia in the code that is antithetical to progress

usually if it's something particularly core, like decoding a bespoke data format, or a pure engine (such as one that will combine and aggregate sports stats from multiple games into one set), I'll write tests to make sure that it will continue to work when we need to change it in the future