Should "functional core, imperative shell" approach canonically break "don't test private methods" rule?

Question

In short, "functional core, imperative shell" can be summarized as:

• functional core implements logic; you unit test it. Your tests call real functions just like in production real functions are called; ie compared to mocking / faking, you don't run a risk that mocks / fakes mildly mismatch behavior of the real dependencies

• imperative shell basically just handles dependencies. It extracts values from them / returns results to them, but has no logic -- everything is delegated by calling functional core. You don't unit test it, because there is no logic to test

So translating this to java (for pseudo-code purposes only, my question isn't java specific), my classes have been looking something like

public class Foo {

  ...

  public int doBar() {
    return doBarImpl(fetchValueFromDB());
  }

  static int doBarImpl(int value) {
    return value + 1;
  }
}

The referentialy transparent / functional core methods are package private and inaccessibly from public interface, but I can still test them by declaring my unit test classes to have same package. This does run against the whole "don't test your private methods" idea. Declaring them public, either in same class or new one, would misrepresent it, because it is ultimately an implementation detail, and I don't want other classes to rely on its existence (naturally this is when functionality isn't generic enough; if it's generic and reusable, then there is no issues / questions to make it public). Keeping it private but testing through public methods throws away the whole benefit I initially mentioned, in that you're not testing method calls directly anymore but start using mocks and fakes and again step into the risk of them not matching the real thing in production. Is my understanding correct, that it is explicitly expected to test private methods in this "functional core, imperative shell" design and ignore the rule of thumb about not testing private methods

Answer 1

I don't see a compelling reason why the splitting between "functional core" and "imperative shell" must happen inside a single class. Since this is known to be an architectural pattern (and not a class design pattern), I would expect these two terms to refer to layers in a system, placed in separate packages, like this

// inside "shell" package
public class FooShell {
  public int doBar() {
    return Foo.doBar(fetchValueFromDB());
  }
}

// ...
// inside "core" package
public class Foo
{
  public static int doBar(int value) {
    return value + 1;
  }
}

But you wrote

Declaring them public, either in same class or new one, would misrepresent it, because it is ultimately an implementation detail, and I don't want other classes to rely on its existence (naturally this is when functionality isn't generic enough)

Sorry, but I think that's a way-too-dogmatic point of view, hence I strongly disagree. If functional core functions are used from the shell package, then they are already "generic enough" to be used and reused from somewhere else, especially from the tests. Just throw your dogma over board - problem solved.

Answer 2

No. You example is temping because it implies that doBar is AddOne() and thus you want to test the adding one to number functionality. But this is a misrepresentation of the general pattern.

You are more likely to have

public class maths
{
   private IRepo database
   public int AddOneToStoredValue()
   {
      var x= database.getValue()
      x = this.addTwo(x)
      x = this.minusOne(x)
      database.UpdateValue(x)
      return x
   }
}

Now do you want to test addTwo and minusOne? I would contend not. You only care that the current db value + 1 is returned and that the db is updated, not the implementation.

You can do both a unit test, where the IRepo is mocked, and an integration test where an actual db is used. These will both have value and won't break when you change the implementation to addOne(x) or some other method.