Ep 108: Testify!

Functional Design in Clojure

Christoph Neumann and Nate Jones, Christoph Neumann, and Nate Jones에서 제공하는 콘텐츠입니다. 에피소드, 그래픽, 팟캐스트 설명을 포함한 모든 팟캐스트 콘텐츠는 Christoph Neumann and Nate Jones, Christoph Neumann, and Nate Jones 또는 해당 팟캐스트 플랫폼 파트너가 직접 업로드하고 제공합니다. 누군가가 귀하의 허락 없이 귀하의 저작물을 사용하고 있다고 생각되는 경우 여기에 설명된 절차를 따르실 수 있습니다 https://ko.player.fm/legal.

2y ago 22:42

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 [email protected], 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!

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?

72 subscribers

published 2y ago

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 [email protected], 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!

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?

플레이어 FM은 웹에서 고품질 팟캐스트를 검색하여 지금 바로 즐길 수 있도록 합니다. 최고의 팟캐스트 앱이며 Android, iPhone 및 웹에서도 작동합니다. 장치 간 구독 동기화를 위해 가입하세요.