- What a great talk
- The origin of the “functional core; imperative shell” notion
- Points out the problem with writing your program in such a way that you need to mock things in your tests in order to test pieces in isolation
- The problem is that if your mocks don’t match the real thing (now or later), your tests will miss problems
- Better would be to be able to call your actual code in your unit tests
- To enable that, write your things using pure functions
- Encourages a fourth paradigm he calls ‘FauxO’ (functional OO) in which you create objects that combine data and behavior, but you don’t mutate state but instead write all pure methods that return new copies of the object
- Talks about 80% of your program being a functional core that’s easy to test
- Wrapped with a 20% imperative shell of “scar tissue” that deals with I/O and needs to care about state, etc
- Points out how important the boundaries you draw in the functional layer are too (i.e. what classes you create) so you can find a readable solution instead of a messy one
Original video by Confreaks:
Some people test in isolation, mocking everything except the class under test. We’ll start with that idea, quickly examine the drawbacks, and ask how we might fix them without losing the benefits. This will send us on a trip through behavior vs. data, mutation vs. immutability, interface vs. data dependencies, how data shape affords parallelism, and what a system optimizing each of these for natural isolation might look like.
Help us caption & translate this video!