LockerNoop is used both in production and unit testing. Certain LockerNoop functions return static values to facilitate unit tests. It is dangerous to use LockerNoop for both purposes, in case a naive test framework (LockerNoop) change introduces a production problem.

A new barebones Locker implementation should be created just for production, and LockerNoop updated accordingly.

Should also look at other Noop classes, to determine whether there are other crossovers between testing and production that could become similarly unsafe – like OperationContextNoop.

I'm unsure whether LockerNoop should ultimately be the just for test or just for production version, once we have a new implementation. It's a naming convention choice.