Question Is it possible to pause a test and explore the scene in the editor?

I can't figure out a way to pause a test while it's running and explore the scene in the editor. If I could do this, I think I could have saved 16 hours of time on this project so far. Is there any way to do this?

Whenever a [UnityTest] gives me an unexpected error, I could save a bunch of time if I could just look at the scene and figure out what's going on. Someone taught me one trick:

Code (CSharp):

1. while (true) yield return null;

This loop will allow me to see what's happening in the game view. I can put that right above a failing assertion and see what's rendered on the screen. That helps in certain situations, but in other situations, nothing beats being able to explore the hierarchy and look at the inspector. Is there any way to do that?

 

I guess you could run the unit test method from an editor script instead of through the test runner?

 

That's an interesting idea. But if I do that, wouldn't the scene be all messed up from the changes in my test?

 

I've never successfully got a playmode test to work. You're saying all I have to do is check one more of these?


I think I'd have to uncheck the Editor box, too, but I'm not sure.

I would love that, though all I really would need is

Debug.Break();

to work in edit mode tests. Or, if there were some way to say, "don't reset the scene after the test" that would work, too. I could just put a return statement right before the failing assert. Of course, I'd need a way to clean up the mess I've made when I'm done inspecting the situation. I'm happy to create a feature request around this if that helps.

 

8 months later ... did this make it into a future build (it's not in 2019.2 - or am I looking in the wrong place?)

Also, incidentally ... Unity deleted the TestRunner docs in 2019.2 onwards ( I'm using the 2019.1 archived version here - https://docs.unity3d.com/2019.1/Documentation/Manual/testing-editortestsrunner.html ) although the 2019.1 docs seem to be valid for my experience in 2019.2

 

I'd also be interested in a feature that allowed inspecting the scene state for failed tests.

I used Superpig's suggestion to debug my test, but it's really fiddly setting this up for edit mode tests. I feel like most of the time it would be enough to inspect the scene after a test has finished if that makes it easier to implement.

 

Well, it's now 18 months since I asked the question , and I stopped using EditorTests entirely - I don't think anyone else I work with uses them either. Without basic functionality like this, there's not much point to them (yes, they're much faster to startup, but ... as soon as one fails, you then spend more time than you saved in total, by trying to debug the un-debuggable).

I hate having to do this multiple times an hour, but its still quicker to use Superpig's method and change:

Code (CSharp):

1. [Test]
2. public void TestAThing()
3. {
4.    // do stuff
5.    // do more stuff
6. }

to:

Code (CSharp):

1. [[B]Unity[/B]Test]
2. public [B]IEnumerator[/B] TestAThing()
3. {
4.    // do stuff
5.    [B]Debug.Break();
6.    yield return null;[/B]
7.    // do more stuff
8. }

(and change it back again after you fix the test ... otherwise your testrunner will pause every. Time. You. Run. Any. Test ...than to waste time using your mental powers to try and guess what has changed/broken in a failing test.

From what I recall ... the current plan is to make Play tests run super fast, implying EditorTests are going to be deleted / obsoleted anyway? I don't mind, so long as we get something that works, and I can stop having to delete/undelete those 3 changes over and over again.

(it's possible to convert everything to UnityTests, and have a "yield break;" at the end of every test - and if I had a large team of first-time junior engineers who'd never learned to unit testing before, I'd probably force them to go that way - but then you have to teach everyone the subtelties that 'everything is now a coroutine' and teach them to stop using the standards for test control ([Setup] etc), otherwise things break in non-obvious ways. ... and you still need to keep manually adding two lines everytime a test fails, and then deleting them as soon as it passes.)

 

My workaround was to save the scene created during the test into a file, and open it after.
Sounds silly, but it worked for me.

Code (CSharp):

1. bool saveOK = EditorSceneManager.SaveScene(EditorSceneManager.GetActiveScene(), "Assets/test.unity");