In our last couple of posts about new Unity features in Rider 2018.1, we’ve seen that updating our Unity editor plugin to be smarter now allows us to control play mode, and bring the Unity console directly into Rider.
In this series:
- Control Unity editor play mode from within Rider
- View Unity console logs directly in Rider
- Run Unity tests directly from Rider
- Unity Explorer and new code inspections
The intent here is to reduce the amount of time you spend switching between Rider and the Unity editor. If you’re working with code, let’s stick to the code editor. And so we can single step frames from the debugger, and see log entries directly in the code editor, and Rider makes the stack traces clickable to easily navigate to the right places in your code.
We believe that reducing this context switching will help you concentrate on your game logic, rather than your tooling, which we also hope will help improve the quality of your game or visualisation. But we want to do more than hope, so we’ve now integrated Unity’s unit tests into Rider’s test runner, making it easier than ever to test your code.
This allows you to run tests that interact with Unity’s APIs, and which can step single frames, all from within Rider. And of course, you can explore the results of your Unity specific tests, just like you would normal tests – you can filter by result, and click on stack traces to navigate your code.
For those not familiar with Unity’s unit tests, there is a constraint that these tests must be run inside the editor application instance. This is because Unity isn’t actually a .NET application, but is a native application, with a Mono based scripting layer, and many of Unity’s APIs are native APIs. If you try and call those APIs in a normal .NET test runner, you’ll see the following rather unfriendly error message:
System.Security.SecurityException : ECall methods must be packaged into a system module
It’s not possible to mock these calls, but instead, you must run the tests inside the editor instance.
Fortunately, our new Unity editor plugin allows us to do just that, listening to requests from Rider to start running the tests, and then reporting back to Rider, where we can integrate the progress and results seamlessly into the standard test runner.
And Unity support is fully integrated with our unit testing experience. We discover unit tests from the code and highlight test classes and methods right inside the editor. Clicking on the gutter icon, or pressing Alt+Enter will show a menu we can use to run the tests.
You’ll notice that the menu shows Debug as well as Run. Currently, debugging isn’t supported, even though the item is available in the menu. If you select Debug, it will simply run the tests. An easy workaround is to attach the editor via the normal debug button in the top right of the main window, and then run the tests – you’ll be able to set breakpoints and debug as normal. We hope to get debugging enabled again as soon as possible.
As if running tests directly from the editor wasn’t reason enough to love this feature, all of Rider’s usual unit testing tools are available, too. You can run all tests in a project or a selection of test classes or even just a single test. You can also group how the tests are shown in the tool window, and filter based on status – passed, failed, skipped.
But best of all, unlike in the Unity editor, where the result output is a block of plain text, Rider will parse the test output, and make stack traces, or even just a class or method name into hyperlinks.
And Rider also includes support for tests marked with the [UnityTest] attribute, not just the traditional nunit [Test] attribute. These are tests with a return type of IEnumerator, where a yield return can skip frames in the editor.
Finally, Rider also includes file templates to quickly create a new test class.
The integrated test runner is supported with Unity 5.6 and above, which is when the test runner was first integrated into the Unity editor. Rider has no special support for Unity tests prior to Unity 5.6, but will run any tests it finds as standard nunit tests.
We’d love to hear your feedback on this and the other new features in Rider 2018.1. Please leave comments here, and you can add feature requests and issues to GitHub or YouTrack. And of course, don’t forget to download Rider 2018.1 and try it out!