Ep 108: Testify!
► Play EpisodeEach week, we discuss a different topic about Clojure and functional programming.
If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack.
This week, the topic is: "testing around I/O". We start testing our code only to discover we need the whole world running first!
Our discussion includes:
- How do you unit test an I/O heavy process?
- Should you be REPL-driven or test-driven?
- What is the REPL suited for?
- What are tests suited for?
- What do you need to know to figure out the bug?
- How can a purely functional language help with testing?
- Techniques for factoring out pure logic.
- What is an extraction function?
- What is an ingestion transform?
- Outside data models verses "internal" or "working" models.
- Code smells when working with external data.
- Where can you use schemas in your code?
Selected quotes
The tracer bullet misfires every now and again.
Now you're going from a tracer bullet to a silver bullet—apparently trying to solve all the problems at once!
The REPL lets you figure out the basics of the process and your own way of thinking about it and modeling it, and the tests let you start handling more and more cases.
Exploration early, testing later.
Are you just supposed to log everything all the time? Always run your code with a profiler attached?
If you look between each I/O step, there is pure connective tissue that holds those things together. We remove the logic and leave just the I/O by itself.
With pure functions, we don't have to worry about provisioning the AWS cluster for the tests to run!
It's really tempting to use the external data as your working data.
What is the data that this application reasons on?
By creating an extractor function, you pull all of the parts that matter into a single place. It returns a map for that entity that you can reason on and schema check.
We've distilled out the sea of information into a drinkable cupful. We've gone from the mountain spring to bottled water.
I guess you could always take all the raw data and shove them off in an Elasticsearch instance for massive debugging later—in some super-sophisticated implementation.
Not how do we accomplish it, but how do we test it?