unity-game-engineunity-test-framework

Is it possible to control the resolution at which Unity runs play mode unit tests?


It is possible to write unit tests for Unity using the Unity Test Runner. I would like to invoke these tests on the command line so I can run them as part of my git workflow in an automated way.

You can run tests on the command line via

Unity.exe -runTests -batchmode -projectPath ~/path -testPlatform PlayMode

This works fine, however Unity always runs my tests at a resolution of 640 x 480, which is not realistic. A major motivation for me to have this tests is also to test for correctness at different target resolutions, which it seems will not be possible.


Solution

  • Similar to your own way but instead of using SizeSelectionCallback which as you figured requires the according resolutions to already exist preconfigured, you could also rather go directly through SetCustomResolution.

    This is not bound to having to preconfigure the resolutions in every project and is also more flexible as it allows to pass in your parameters as test cases or even as CI sided console arguments! (See System.Environment.GetCommandLineArgs)


    Further instead of going through Reflection, I usually prefer to use the "assembly bridges".

    Unity exposes the internal types to certainly named assemblies such as e.g. Unity.InternalAPIEditorBridge001 up to Unity.InternalAPIEditorBridge024 using the [InternalsVisibleTo] attribute. (See source code)

    By just simply creating an assembly(definition) with according name you gain direct access to all UnityEditor internal types and methods so that instead of Reflection you can then simply use

    var gameView = EditorWindow.GetWindow<UnityEditor.GameView>();
    gameView.SetCustomResolution(someResolutionVector2, "TestResolution");
    

    This special assembly and your tests you could in theory even export as a .unitypackage (not to confuse with the Package Manager) and then import it into an existing project as part of the CI (-importPackage <pathname>) without even having the tests itself in your original project. But that if course makes sense only for very generic tests that are repeatable in/for all your projects