A few months ago, Kent Dodd wrote an article highlighting a maxim about testing philosophy which is totally backwards. It goes: "Write tests. Not too many. Mostly integration." On the first point, I agree. You should be writing tests for most all the code you write. It not only helps you for regression testing, but also as a tool for iterating on the design of your code. The second point ("Not too many") is where I start to scratch my head. I have yet to work at a place where too many tests are the problem. TDD is a discipline, and like all disciplines, it more tempting to neglect it than to overindulge. So recommending you "not write too many tests" is pointless and harmful advice.
This article is intended to help you methodically incorporate rad Functional Programming (FP) techniques into your everyday work.
It will not try to convince you that FP is a good idea (if you want to be convinced, read anything Eric Elliott has ever written on the subject) nor will it detail FP concepts or how to implement them. For an introduction on the problems and solutions outlined here, watch Brian Lonsdorf's talk, of which this article is tightly based on. In fact, this article is basically an outline of his talk, but with some practical advice and dank memes sprinkled in. Let's get started!
Virtually every program you write will have to deal with errors somehow. And doing so almost always requires recording a message which describes what went wrong. Most often, people will construct those messages inline like the following:
What follows are a list of language-agnostic principles and best practices I have found to be quite helpful when writing unit tests. Let me know what I missed in the comments!
Over the last decade, the software industry has slowly been moving away from classical-inheritance in favor of more compositional patterns (mixins in Ruby, traits in Scala, etc.) and its begs the question: what happens to the OOP design patterns we've all come to know and love (or hate 😬) in a post-inheritance world? Additionally, what happens to these patterns when we have the full power of functional programming (first-class functions, partial application, monads, etc.) at our disposal?