Fork me on GitHub
#testing
<
2020-03-24
>
Bill Phillips20:03:17

Hey y’all. I’m very very new to clojure; not new to unit testing or TDD, but new to having an REPL in my dev flow

Bill Phillips20:03:38

I’m curious to as how best to structure my code… I want to be able to spin up a usable REPL, so I have an repl.clj in my src folder with various utilities. But now that I want to move on, I want to put those in my tests. It feels like I may be better off scrapping my approach and copying a good example of how someone else structures things instead

seancorfield21:03:36

Hi @jings.bill My approach is to have the equivalent of repl.clj in a dev folder so it doesn't end up getting bundled into a JAR or anything, and then I have a :dev alias that adds that dev folder to the classpath when I'm working locally. So that part of our workflow overlaps.

seancorfield21:03:35

I have a pretty tight "RDD" workflow in that I run a REPL, connect my editor to it, and never type into my REPL -- I only ever type into source (or test) files and eval code with a hot key from the editor. The important aspect is to edit/eval/edit/eval in that very tight loop -- and I often eval forms without saving the code several times as I'm building up my code. I use "Rich Comment Forms" (that's what Stu Halloway calls them, based on Rich Hickey using them 🙂 ) which is a (comment ...) form in my source (or test) file that contains the code I'm working on as it evolves, and that becomes actual source functions and test functions as I get enough code evolved.

seancorfield21:03:23

Stu talks about this in his REPL-Driven Development talk (to the Chicago Clojure Meetup a few years back) and also Running With Scissors which is a more recent talk (to Strange Loop perhaps?).

seancorfield21:03:01

If you want to spend a bit of money for an online video course, I'd highly recommend looking at Eric Normand's REPL-Driven Development course. I think it's excellent.

seancorfield21:03:49

These all emphasize how central the REPL is to your workflow, and so testing should naturally evolve out of that.

Bill Phillips21:03:01

Thanks so much. How do you handle code that you use in common between test and dev?

seancorfield21:03:40

Since I have dev, src, and test on my classpath for dev work, "common" code can go in test namespaces and the dev stuff can require it as needed.

seancorfield21:03:58

(assumption: you need run :dev without test code present)

seancorfield21:03:15

Here's an example RCF from a source file (not a test file -- since I work in source files to evolve code):

(comment
  (require '[clojure.test :refer [deftest is]])
  (deftest example
    (is (= 0 (sys/ip->long "0.0.0.0")))))
So I can actually write tests directly in the source file as I'm working, and then cut'n'paste them into a test file once I have them figured out.

❤️ 4
seancorfield21:03:00

And that means I can eval each form in that RCF as needed and I can run an individual test or "all tests in the current namespace" via hotkeys from inside my editor.

seancorfield21:03:31

So I stay in my editor all day long and only rarely need to run tests from the command-line as a sort of "sanity check" (usually before committing code).

Bill Phillips21:03:30

Yeah, that’s exactly the flow I’m looking for. The REPL gives me all I would want from a test driven flow and more, so it’s more a matter of moving the products of that flow into cold storage rather than forgetting them