This is a nice piece of work. My comments are stylistic.
- Extra newline at the end of MyInjector, probably IDE induced.
- Why do you access EFI.instance directly? Doesn't FB whine at you about having a public instance variable that you're accessing directly, or do we disable that check?
- MyInjector is always init'd with 1,1. Perhaps just make a no-args ctor instead?
- Naming. EncryptionFaultInjector is a relatively general name, and startFileAfterGenerateKey is more specific. But I wonder if this should be turned into a more general facility, including naming. I'm thinking something like:
TestFaultInjector or DebugFaultInjector instead of EncryptionFaultInjector. And then perhaps startFileAfterGenerateKey could be renamed to injectFault or just inject. generateCount is more like an injectCount or injectionCount or callCount or just count.
- If you drink that glass of Kool-Aid and agree that things could be more generally named, then you'll perhaps buy into making this a slightly more general, reusable facility (DFSTestUtil). There's repeated code:
injector = new MyInjector(1, 1);
EncryptionFaultInjector.instance = injector;
future = executor.submit(new CreateFileTask(fsWrapper, file));
assertEquals("Expected a startFile retry", 2, injector.generateCount);
So maybe the creamy filling in between those two blocks (e.g.):
fsWrapper.mkdir(zone1, FsPermission.getDirDefault(), true);
could be turned into a Callable?
Of course, the fly in the ointment is the last test ("Flip-flop between two EZs to repeatedly fail") which doesn't exactly follow this pattern, so maybe this is unattainable. I'm happy with this being a follow-on Jira if you think it's a worthwhile endeavour.