Unity Test Tools 1.3 — responding to your feedback
Hi again! This time is will be much shorter. The 1.3 version update for Unity Test Tools is out and I want to share some of the goodness it brings to you. You can get it via the Asset Store (as usual). So, what’s new? Let’s start with…
Due to some inaccurate assumptions we made in the beginning of the development, we eventually run into issues preventing us from taking full advantage of all the features nUnit provides. With some UI refactorization (mostly “behind the scenes”) we managed to overcome some limitations we had in the previous versions. It’s possible now to use [Random] attribute in your tests as well as other nUnit functionalities that were missing. For your convenience (and fans of [Explicit] attribute), we made all tests dimm after the code’s state changes, so you know the result are outdated.
We hope your test suits have grown big so far, up to the point you find it hard to manage the test list. To come up against this issue, nUnit’s [Category] attribute can now be used and the tests filtered according to it. If any test has the [Category] attribute set, in the unit test runner a multiselectable dropdown will appear
If you select one or more categories from that dropdown, only tests that belong to selected categories will appear on the list and will be run.
Last but not least, the test runner will now scan for tests all dlls in the project that contain reference to nunit.framework dll. This allows you to run tests from external assemblies or simply to keep your own tests in a separate project.
Some of you who actively use the integration tests framework and write many tests asked for a way to write and manage tests purely form code. It surely would make some of the tests easier to maintain, especially when you have *lots* of them and you need to change one thing in multiple scripts. We’ve heard you out and implemented dynamic integration tests. If you prefer to setup your test fully from code, all you need to do now is to add [IntegrationTest.DynamicTest] attribute to a MonoBehaviour class and provide the name of the scene you want it to be included on. The MonoBehaviour script will be created on the fly by the runner if the name of the scene match the name provided in the attribute. The dynamic tests are marked with HideFlag.DontSave and will not be saved on the scene. This approach allows you to have an overview of your whole test suite, include the dynamic tests.
Another often requested feature from you was a possibility to…
Instantiate AssertionComponent from code
If you feel like the number of assertions you set on your GameObject becomes too big to manage from the Inspector, we created an API just for you! From now on, you can simply instantiate the assertion using few lines of code:
This code chunk will result in creating such assertion:
For more complex configuration you will need to get AssertionComponentConfigurator object and use it to configure the behaviour:
If an assertion instantiated from code fails, you will get in the log message the location of the code that created it:
Collaboration and your input
You are an awesome and invaluable community (I hope you all know that) and some of you are very eager to contribute to the tools. We hope we will find the best way to make it possible for you as soon as we can!
13 КомментарииПодписаться на комментарии