Assert attributes

Unity Engine
1

like this

[Assert.IsNotNull(prefab)]
public GameObject prefab;

do they exist?

2

No.

How would that work, anyway? It’d fail the assertion the instant you attached the behavior to the object…

1 Like
3

Attributes are all decided at compile time- you can’t edit them, you can’t point them toward instance members of any kind- they’re basically like constants, in a way. It isn’t this easy to make what you seem to want, sadly.

First you need to make a new attribute type, for instance “Required”. This attribute should only ever be applied to UnityEngine.Object-derived field types. This part’s super easy.

Second, you need to make a property drawer for the Required attribute, so that displaying a field with that attribute will show a warning/error image, and/or a short message “This field is required.” when displaying that field in the inspector, if no reference is assigned yet. This part is more complicated- you’ll have to look up tutorials and guides on property drawers if you haven’t delved into that yet.

Third, you need to make a static function somewhere else, in an editor script, put the MenuItem attribute on it so you can run it from the Unity editor menu, and make the function first find all types that possess Required attributes, then seek out all MonoBehaviours/ScriptableObjects in the project (currently loaded scene and project assets- Resources.FindObjectsOfTypeAll will help with this) which match those types, and check each Required field for each and see if a reference is assigned. You’ll then need to return a list of objects that meet this criteria, so that you can select them and try to fix the problem.

This last part isn’t at all trivial- property drawers are one thing, but it would take reflection and a pretty serious knowledge of the Unity editor to get it functioning properly. I have this exact functionality in my own assemblies, but it’s so deeply ingrained in other systems I’m not sure I could separate it out to give away. You may want to try lordofduct’s Spacepuppy framework, as I believe he has a Required attribute as well, though perhaps it only goes so far as the property drawer stage, and not the “search all assets” functionality.

3 Likes
4

If you really want this, a dependency injection framework might help. One of the advertised advantages if these frameworks is checking for dependencies before running.

5

I think @DonLoquacious has given a great detailed advice which you can use in order to tackle alot of editor-time validation in a clean manner.

However, if you’re not that much into editor and inspector customization and only need such validation every now and then to check a behaviour’s values at editor time, you might find Unity’s Reset and OnValidate messages useful as well.

These are only called in the editor and can be used to reset and validate a component’s state when someone or something messes around with its exposed values. It’s a simple and straightforward way to enforce validation in the editor.

Be aware though that you might end up writing similar validation logic over and over again. At some point, custom attributes may be more convenient.

1 Like
6

thanks guys, it’s too much work so I’ll give up for now and pester or inspire unity devs to add this :wink:

7

could c# code contracts be what you’re looking for?

(I haven’t used them or tried them in Unity though)

1 Like
8

Not as attribute but interesting to have runtime assert. I’ll keep that in mind for the future.

9

ah yea, my mistake. I know you still need to write a contract but I had browsed the article and was under the impression that you attach the contract by decorating your classes… it still separates verification stuff from your actual logic, so you don’t need to clutter your actual functional code, which i think is quite nice.

btw you already have runtime assertions in unity: Unity - Scripting API: Assert, just not as attributes.

However, it just occurred to me that you can implement your own pretty easily by defining your own attributes (or use existing ones from .net) and just weaving in the assertion into the decorated methods using malimbe, harmony, direct use of cecil (if you’re feeling spry), etc. *

you have tons lots of options here… including stuff based on emit, since you’re presumably not going to have these checks in production AOT-only il2cpp code right?

please post if you do this, or find any other options… i’d be interested in hearing about it / checking it out.

  • I’ve tried malimbe, which is based on the widely used fody, and it’s quite nice and easy to use, but found my team was wary of weaving runtime code :confused: i’ve also looked into harmony, which is super cool since its nondestructive & reversible (i.e. doesn’t modify your assembly), but was turned off by it not working if your method gets inlined and didn’t dig into a workaround

EDIT:
also, if you’re wary of weaving, you could just write a static method that can validate any object by using reflection to find and check decorated fields. you’d have to invoke it manually from awake or something + reflection is relatively slow, so it’s not quite as nice as weaving IMO.

1 Like
10

Thank you that is very interesting. I’ll post when I zero in on something I like, it’ll definitely be the easiest.

You’re right I won’t use emit since it’s a Switch game, also I don’t have the skill anyway :smile:

I looked at Malimbe doc.
Why is your team wary of weaving? Are there risks that malimba changes the behavior of the game?
BehaviourStateRequirementMethod seems wicket powerful but then don’t you run into the unit test syndrome of spending more time writing tests? I guess it ensures that contract are respected, i’ve never done any of it so I ask random questions.
Do you use MemberChangeMethod? what’s the use scenario?