Last week I said I was going to talk about the process of writing a test but instead let’s revisit this blog entry about dependency injection. Since then I have done two rather interesting things. The first is that I have started to make editor scripts. I have found that there is a really nice way to make the editor scripts which I have bundled in the test utilities github repository. I have been talking about. Essentially though you can create a basic visual tree asset and then add in some buttons and labels in script. To make this even easier I made some static functions which make the process a one liner like this:

InspectorHelpers.AddButtonWithFunction(mainInspector, "Name on Button", FunctionToInvoke);

Edit: I have found classes with complicated serialised variables adding new buttons via this method can cause the layout to not be populated correctly. In which case you should create your own layout and query it for the buttons (talk about needles breaking the camel's back).

Which means instead of writing the editor only functions in your scripts and using compile directions, you can just write them as normal functions and call them from your editor script. The main motivation funnily enough was that I wanted to get my code coverage numbers (a metric to show how much of your code base is called during your tests) up - since I was not calling the editor only functions from tests since for a lot of them the test didn’t really make much sense. Of course code coverage percentages don’t mean anything in and of themselves. They are easy to cheat, you just run the functions and don’t assert anything. The point is that they are metrics I can show off that say I at least take my programming seriously enough to know what code coverage is. So by splitting out these functions to… where they should have been in the first place… they make more sense. Hardly a revelation, I guess, but it is great that I can actually write simple editor scripts… simply.

Of course I talked about more than just editor scripts in that blog entry. I also talked about dependency injection. I have made a new discovery or rather I found a way to use something I discovered other people talking about. That is using scriptable objects for dependency injection. Now when I first read about it, I had some concerns with the idea. Scriptable objects exist between scenes so could you get into a situation where by changing scenes you would have the wrong instance, right? Actually I am not sure that it works that way. I have found forum posts where people have tried to get the don’t-destroy-on-load behaviour from this technique and failed. As I was looking into making editor scripts for the dependency injection classes I looked at the editor only functions and remembered my research several months ago. It was at that moment I realised something - if I am worried about the instance existing across scenes… why don’t I just remove the reference on scene load? I did some tests and… when I changed scenes the instance was cleared and destroyed exactly as expected. The advantage was that I could hook these scriptable objects into my existing dependency loader classes and then assign the references to this scriptable in the inspector. This was huge for my work project where I had a lot of scripts that needed references injected. Now my solution of running the editor script to automatically set all the references would work providing that nothing was created during runtime. Of course things were created during runtime. So I made a compromise and had a singleton which the classes could request a reference from. With this solution though you can assign some references during edit time and in fact you can even use resources.load to automatically set the reference and then without any fancy footwork everything has references to each other. 

That’s all my thoughts for this week - see you next time.