inspector glitch, anyone?

Did you tell QA? Could you post the case #?

 

I've got a repro, the tricky part was that the bottom view in Profiler needed to be in Hierachy view with a Details View on the right hand side (not open by default but state saved to Editor Prefs, which is probably why you missed it in the repro steps and QA missed it when trying to repro). GPU or CPU doesn't matter. Oh yeah, and you also need to be profiling or have some profiled frames loaded, otherwise, Hierachy is showing nothing.

I'll fix it asap, thanks for reporting

 

Fixed it, it might be a while until it goes through all the motions and lands in a beta release down the road, though.

 

yes, every change needs to first pass a series of reviews and tests before it gets merged into the main line (trunk) and then again for a backport into an already branched off beta cycle like in this case. We're taking the potential for regressions serious and we also don't want bugs fixed in the beta and suddenly reappear in trunk so that's why it's this slightly staggered process

 

Well, in this case the change is very contained and will not really get tested, but the changeset still needs to go through our entire test framework to verify that didn't break anything. There are tests that might fail if the fix would contain more involved changes e.g. somewhere deep in IMGui Code. Also, there are UI automation frameworks that would simulate button presses and can read window contents, but they aren't used here.

So yeah, the testing for this fix is mostly there to uphold the process so I can't just claim: here's a fix, it wont break anything.

Also, QA will have to verify this fix before the relevant build would be released.

 

We have some internal tooling for that and with that it looks somewhat like this:

Code (CSharp):

1. using UnityEngine.TestTools;
2. using NUnit.Framework;
3. using UnityEditor;
4. using System.Linq;
5. using UnityEngine;
6.  
7.     [Test]
8.     public void CanClickOK()
9.     {
10.         InspectorWindow inspector = EditorWindow.GetWindow<InspectorWindow>();
11.         using (var automatedInspector = new UnityEditor.UIAutomation.AutomatedWindow<InspectorWindow>(inspector))
12.         {
13.             var okButton = automatedInspector.FindElementsByGUIContent(new GUIContent("OK")).First();
14.             Assert.NotNull(okButton);
15.             automatedInspector.Click(okButton);
16.         }
17.     }

There are some caveats and gotchas when using this like, if the element is not visible, it can't be clicked. Since our build/test farm runs the windows unmaximised and at a low screen resolution, tests like that can be rather unstable if you're not careful about the window setup. I think that's one reason why it is not used too much, the other being that we're exposing a lot of API so the need to go through a window to test functionality isn't that huge and UI tests are pretty high level and therefore slower and more prone to breakage as we rearrange stuff.


A quick google search revealed this small package for ingame UI testing:
https://github.com/taphos/unity-uitest
https://assetstore.unity.com/packages/tools/unity-ui-test-automation-72693
I glanced over it and it seems to offer some similar functionality.

 

You're right and testing layout would be a whole other mess I fear. I just had a discussion if we could ad some tests or safeguards for this specific case but it seems impractical at this point. But I'm glad I could shed some light on the testing process