Jon Lim blog

Link to YouTube video

Transcript

What you know you can’t explain but you feel it. You’ve felt it your entire life, that there’s something wrong with the world. You don’t know what it is, but it’s there like a splinter in your mind driving you mad. – Morpheus the Matrix

I feel this movie quote applies to software development. That’s why the goal of this video is to go over some test development workflows. I’m new to F sharp and going through this book Get Programming with F# by Isaac Abraham. I’ll review the chapter on development test workflows, some pros and cons, go over what the REPL is, and conclude with some final thoughts.

Let’s start with an overview of some development test processes. A logical beginning is no test tooling at all. Here you change your application and then run the application to check your work. Next, test harness. The book’s context on this is a bit ambiguous, but I believe it means that you have a separate program that tests your main program so you change your application and then run the test harness that then checks your work for you. Finally, unit tests. The book briefly goes over unit testing in terms of test-driven development where you code a test then change your application to make the test pass and repeat.

Now, let’s review these three test workflows and go over some pros and cons. First, manual testing. Although there’s no test tooling that can go wrong, and you won’t waste any time coding, there are some drawbacks. It can be inefficient because you’re manually checking your work. This can get tedious as you repeatedly run the application. And, it’s tempting to slack on checking your edge cases. Second, test harness. With a test rig you have automation, but it’s a standalone program so as you change your main application you will often need to change the test harness as well. As the test harness gets more complex this can get costly in terms of time and effort. Also sometimes the test harness can slow down. Third, unit tests. With the unit tests, you get regression checks for free and automation as they run whenever you build. But, the unit tests can be difficult to code properly and they’re not ideal for checking out nuget packages.

Now let’s go over the REPL. The REPL stands for read evaluate print loop. It is a standalone tool where you enter code and get immediate feedback. You can do many things with the REPL. You can develop new business logic, debug existing production code, try nuget packages, or do data analysis and exploration. You can invoke the REPL from the command line or from the editor. To submit code to the REPL you can use source code from your project, fsx script files, or load binaries such as dll’s.

Let’s conclude with some final thoughts. As devs we should seek to uncover better ways of developing software. The book goes over some test workflows for development. In general, I agree with Mr. Abraham’s points about the pros and cons of the tooling. I don’t have much experience with F#, but I’m excited to try out the F# REPL. It is a standalone environment. This could cause problems because you could start in a different working directory than your application leading to unexpected results with their paths. Or, your main application may have imported nuget packages and these would need to be synced up with the REPL. But, overall, I believe experimenting with F# REPL is worthwhile.

Thanks

This post is an entry in the 2019 F# advent calendar hosted by Sergey Tihon.

Book summary from Get Programming with F# by Isaac Abraham

DJ and 42 san for helping a noob