mascip

In my last article I introduced a design technique called Functional core and Imperative shell (let’s call it “FC&IS”). It enables to do isolated testing without using test doubles (mocks, stubs). It’s also said to produce better designs (I’ll let you judge of that).

My post was a bit abstract and introduced quite a bit of vocabulary. Now I’m going to make it a bit more real by showing some code. Writing this code also helps me re-arrange and crystallize my understanding. Here we go!

Following Ovid's Sick of being mocked by unit tests and the link to the discussion is TDD dead between Kent Beck and others, I found this talk and it seems like a promising solution. I'm writing this post to share it with you all, but also to clarify ideas for myself.

The original goal is to do isolated unit testing without using Test Doubles (mocks, stubs, etc), and the method is called "Functional core & Imperative shell". According to its creator it also leads to cleaner design, which is more important than testing in the end. So we're fetching two stones with one bird.

Here is how to do it in theory:

Would it be doable, to have a module to activate immutability with Moo(se)? Something like

with MooX::Immutable;

which would make all the objects from the class immutable.

In my previous post I spoke about what Subroutine attributes are and how to use them. Here I compare them to other techniques for introducing orthogonal behaviors: Method modifiers and Aspects. These three techniques enable to modify what a subroutine does, but they do it in different ways and are thus suited for different needs.

I watched this video about Subroutine attributes, and I wrote myself a summary of what I learned. I thought I could share it.