There are many different ways to address such scenarios, but fundamentally you need the production code, when invoked from unit tests, to not use the real Quiddity value but instead some artificially "injected" value.
If you have written code in a way that allows mocking (i.e. your logic is not in static methods and you use some dependency injection approach) it's simply a case of introducing some form of "Quiddity Accessor" interface, with an appropriate method, so all access to Quiddity is done through an implementation of that interface. The specific implementation used then depends on the code being run in production or through a unit test. This is my recommended approach, but there is a lot more setup needed (so I'm not showing it here).
If you have not written code that allows mocking (e.g. you use static methods everywhere) you can still take a similar approach. However, instead of using an interface for the "Quiddity Accessor", you'd write a class similar to the following:
public class QuiddityAccessor {
public static System.Quiddity quiddity {
get {
if (quiddity == null) {
quiddity = Request.getCurrent().getQuiddity();
}
return quiddity;
}
set {
Assert.isTrue(Test.isRunningTest());
quiddity = value;
}
}
}
All production code would get the current request's Quiddity simply be using QuiddityAccessor.quiddity
instead of Request.getCurrent().getQuiddity()
.
When a unit test wants to call some production code that relies on Quiddity and needs to provide a specific Quiddity value, it would simply set the value via QuiddityAccessor.quiddity = Quiddity.QUEUEABLE
, for example, then invoke the production code and assert the results.