To solve this I might need to rethink the approach entirely.  I can't just wrap the ``memories`` variable in ``Thread.current`` because I'm changing a class constant at runtime.  So if things are running in parallel *in the same ruby process* then that bleeds across boundaries too, e.g. if half way through a test that wants the real ``GovUkNotifier`` we swap it out for the ``RememberingNotificationEndPoint`` one for this test in another thread and then that original test will break.  I could using stubbing, or monkey patching to achieve something like the same result, but that wouldn't be thread-safe either.  Mocha's mocks are not thread-safe (I asked @floehopper, and he opened https://github.com/freerange/mocha/issues/152 ;) ).  I'm pretty sure that monkey patching isn't thread-safe for the same reasons - we're mutating the classes at runtime and I don't think ruby's class structure or object graph is per-thread.

But, taking a step back, I'm pretty sure that most (if not all) test parallelisation tools work through forking, so we're safe from all thread-safety issues if we use that approach.  

I think this is a good spot, I'm just not sure we actually need to worry about it (particularly as we're using mocha everywhere and it's not thread-safe either).  I will drop a comment here saying it's not thread-safe though.