Friendly tip: try not to rely on singletons. Those seems fancy at first but are more trouble than they're worth in the end. Just pre-instancing them manually in the editor and accessing them through fields isn't that hard and will make your program more resilient. Meaning just:
[SerializeField] BuildManager _buildManager;
then:
_buildManager.ExitBuildMode();
instead of:
SingletonMB<BuildManager>.Instance.ExitBuildMode();
For rapid prototyping those worked awesome for me :) I didn't aimed at having a lot of unit tests yet, nor did they gave me too much of a trouble so far, so I didn't invested much time into finding other solutions. Most of them (if not all) are used as a sort of API by various systems, so I need easy access to them. Do you think switching to service locator pattern will be a good enough choice? https://erdiizgi.com/avoiding-singletons-in-unity/
It seems it will allow me to use dummy classes for unit tests and have control over when they're instantiated
I have no idea what service locator pattern is and I'm glad for it! :T
In my personal experience implementing patterns is very luring but only to become a very costly vanity work (and sometimes even deadly one to given project). Because in later stages of development everything becomes so horrendously complicated that everyone is praying for simplicity, productivity stalls.
Keep it simple - this is most undervalued yet most productive pattern out there (!).
Unit tests are of some value Only when you find yourself actually testing something manually a lot and would love to automate that - in other situations it's mostly another costly vanity coding.
Exception #1: Big enterprise software, where codebase maintenance and stability is more important than change (creative work does that a lot)
Exception #2: Well staffed MATURE game projects going for stable release
