When creating the SimpleNamingContextBuilder for a second time, it doesn't work well. Different testcases can cause eachother to fail. The second will be missing it's JDNI settings.
This is caused by the fact that the first SimpleNamingContextBuilder is still connected to the NamingManager.
In your test code, why do you call builder.deactivate() and builder.clear() explicitly? Keeping the original builder activated makes the test pass, and clear() is a no-op after an emptyActivatedContextBuilder call...
And through your workaround, you effectively make deactivate() a no-op since you hang on to same builder instance nevertheless, taking it from your own field rather than from activated. We could only really fix this through skipping deactivation as well which seems backwards given that you're calling deactivate() explicitly.
The deactivate in my workaround is not a no-op. The original context is used after calling it.
Because a new builder can not be set again, it used the stored old builder.
The real problem is that you can easily have two different builder. One on the stack and a different one in the NamingManager. This leads to strange testcan results, that will be depend on the order which they are run.
I see three solutions:
Reuse the first builder.
Throw an exception on any use after a deactivate.
Change the builder in the NamingManager through introspection.