Back

@jamesshore To aid in my own understanding, I tried to fit this into my own schema of testing approaches, and figure out the major decisions this approach makes. This might be useful feedback, or it might just be repeating the original idea in my own (less coherent) words. Or I might just have misunderstood it all. Let's find out!

@jamesshore Question #1: where do you switch away from using production (whether that be code, data, infrastructure, or something else)? Or, to put it another way, what do we fake? The typical case with mocks is to fake the immediate dependencies with mocks. In the opposite case where we run the full system, it's the config that's fake: the stack of code is completely real but we (for instance) change a config file to point the system at a different database (again, running for real).

@jamesshore Nullables says that we should run as much of our own code as possible, but avoid using real infrastructure. So, we fake out those dependencies on infrastructure at the lowest level e.g. faking out `stdout.write()`.

@jamesshore One possible advantage: if you're mocking immediate dependencies, then you end up mocking an awful lot of your interfaces at one point or another. Faking out dependencies at the lowest level might well mean a much smaller, and therefore more manageable, set of interfaces that you have to fake.

@jamesshore Question #2: how do we make the fakes? Rather using a mocking framework, or making the real thing with different config, we create embedded stubs. One way to think about them is as in-memory implementations of the interface. For instance, instead of writing to stdout, we just stash the value in a field. Instead of checking what was written to stdout, we check the stashed value. Instead of reading from stdin, we get the value to return from a field.

@zwobble Also, the output tracking is unrelated to the stubs, and works the same regardless of whether you’re using a Nulled instance or a normal one.

@jamesshore To check I've understood: "works the same" in that you can always create an output tracker using the exact same mechanism, both in production and tests, even if you don't actually do so in practice in production?

One of the other nice things about colocating code in that way is that it makes it more natural to add those sorts of affordances that make testing easier.

@zwobble Yes. You call e.g., `log.trackOutput()` and you get the same results back regardless of whether it’s Nulled or not. There’s an extensive example of how it works for both JavaScript and Java in the article.

@zwobble (under “Output Tracking”)

@zwobble @jamesshore I think James' is using the fake/stub terms from Mestaros' _xUnit Test Patterns_ http://xunitpatterns.com/Test%20Double.html

@pdmoore @zwobble I got it from Fowler's "Mocks Aren't Stubs," but he got it from Meszaros's book. https://martinfowler.com/articles/mocksArentStubs.html