Ep 109: Extractify!

Functional Design in Clojure

Each 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 [e-mail], or join the #clojuredesign-podcast channel on the Clojurians Slack.

This week, the topic is: "separating data from I/O". We need to test our logic, but the I/O is getting in the way.

Our discussion includes:

• Bugs in our Clojure code? What?! You must mean Javascript.
• When does Hammock Time not help?
• How logic grows and expands.
• Why you should test your logic.
• What parts do not need testing?
• What's a functional approch to working with APIs?
• How do you separate out logic for complicated I/O sequences?
• I/O testing without mocks.
• Why do we create our own model when Java gives us a class model already?
• The problems of built ins.

Selected quotes

• We're using Clojure. Everything should be perfect, right?!

• I love Hammock Time for figuring out hard problems, but in this case, I think we have a simple problem of testing.

• You got to have the right amount of celebration after all those "line crossings" and "goal scorings" and stuff.

• We're doing a relatively simple process: we're downloading things and compiling them together into a file. But, it's amazing just how much logic is all throughout this process.

• As soon as you make a process, there's always going to be people who want to do it differently!

• If experience is any indicator, you always need more information.

• One of the reasons why you test is, when you make this kind of logic change, you want to make sure that everything continues to function.

• You need to write tests so that when you make future changes, your old self is there sitting right next to you making sure that the old use cases are all covered, so that you only have to think about the new use cases.

• With REPLing, you're figuring it out. With tests, you're locking it down and making sure that you have coverage in different situations.

• Our biggest obstacle here is that logic and I/O are mixed up together.

• Wait! Wait! We want to test our code. We don't want to spend our life writing code. Did you write the mock correctly? How do you write a test for the mock?

• I think we need to completely pivot our approach here.

• The problem is that we have I/O, logic, I/O, logic, I/O, logic. We have those two things right next to each other. What we should do instead is completely invert our thinking.

• Let's gather information and then we can do pure logic on that data. Separate those two things.

• We're going to extract from those POJOs. [Groan] I've got to use these terms every now and again or else I'm going to forget them all.

• So we do an I/O call, collect information, and create our own internal representation. We just need a few bits of it, so we create a working representation of that.

• It's our representation. It's our program's way of looking at the world. Craft the different scenarios in data that represent all the real life situations we found.

• One of the problems of using built-ins is: what parts matter?

• We're accreting working information into a larger and larger context.

• You're setting the table with all the pieces that are defined in your working world and then creating unit tests in terms of those.

• The world was like, "Hold my beer!"

Links

• Sportify! series:
  • Ep 101: Sportify!
  • Ep 102: REPLify!
  • Ep 103: Explorify!
  • Ep 104: Assembleify!
  • Ep 105: Codify!
  • Ep 106: Robustify!
  • Ep 107: Idempotify!
  • Ep 108: Testify!