• UnityTestTools測试工具


    由于工作关系,要了解Unity上的測试工具,该工具基于Nunit框架。通过查阅资料了解到在Unity5.3中做出了一些改变,自带的仅仅剩下单元測试工具,假设想用其它的工具比方断言、集成測试,就须要前往Unity的应用商店搜索UnityTestTools进行进行下载,期待之后的版本号整合很多其它更强大的功能。


    測试工具包括

    集成測试框架Integration Test Framework
    集成測试同意您在一个场景自己主动验证过程。

    在现有内容里直接在编辑器中构建測试验证报告。

    断言组件Assertion component
    断言组件能够让你的游戏对象给予你所期望的状态。这是一个可视化工具,不须要编写不论什么代码。它被设计为可扩展的,适应项目的内容和您的须要。

    单元測试执行器Unit Test Runner
    NUnit框架的集成编辑器同意从Unity里执行单元測试。

    这意味着你能够实例化GameObjects和在Unity里面操作。

    官方提供了一个集成的測试执行器,便于查看測试和执行的报告结果。

    PS:

    通过文档我们了解到Unity的測试工具一定要求在Editor目录下才干够使用。


    測试的结果有下面几种:

    1.Success成功,又分为本身測试的通过,或我们在这之前就了解将会抛出的异常,也算測试通过。

    2.Timeout超时。測试没有在我们要求的时间内达成。

    3.Fail失败。測试的失败。作为QA測试的同学最好在检查源码之前,再三查看是否是自己的測试代码出现故障。

    4.Ignored忽略错误。执行測试时忽略一些測试


    断言组件


    通过文字并非那么好了解到详细的用法,以下我们通过一些案例来了解怎样使用Unity中的測试工具。

    在Unity測试工具中有个场景叫AssertionExampleScene,描写叙述的是一个球体自由落体掉落在平面上。


    我们在Sphere上找到了两个断言组件,为了便于观察,我们来看第二个断言组件。看之前我们先了解一下断言组件中都有什么功能。

    PS:測试组件在Inspector中点击Add Component选择Scripts--Unity Test下就能够找到了。


    1.比較方式选择器,定义应该怎样比較两个值。它决定了断言的结果。

    2.測试的频率,你能够明白指定断言什么时候開始。或者在什么条件下開始。

    3.自己定义菜单频率选项,平时是看不到的,详细要依据2的选择,才会开启这里。

    3a.多少秒以后第一次触发。

    3b.是否须要反复測试。

    3c.多久反复測试一次。

    4.一样也是自己定义菜单频率选项。可是他和3并不冲突,当你同一时候选择了After Period Of Time与Update的时候,就会出现两个自己定义频率菜单。功能同样。

    4a.在多少帧以后測试应该做的。

    4b.是否须要反复測试。

    4c.多久反复測试一次。

    第一个用于比較的GameObject。

    6.自己定义选择比較器,他们定义操作类型和精度。比方当比較两个浮点数时,可选操作类型有相等,不相等,大于,小于,而且能够确定他们的精度,比方在Floating Point Error中,输入0.01。则就是精确到小数点的后两位。

    7.用于比較的第二个GameObject对象,能够与另外一个GameObject比較,或者是一个静态值,或者Null值。

    8.依据7中你所选择的不同而改变,当7中为GameObejct选项时。这里让您拖入另外一个GameObject。假设7中为Constant Value时。这里则让您输入详细的參数,当7选择Null则消失。

    相信看完以上描写叙述以后,对于下面的这幅图大致了解是什么意思了吧,比較的是球体对象与平面对象的Y轴值。我们断言球体的Y轴一定大于平面,说人话就是球比平面高。假设球小于平面就抛异常,我们就RUN一下来測试一些断言组件吧,在这之前记得先关闭另外一个断言组件噢。


    点击播放以后我们能够查看球体做自由落体而且向平面的边缘滚去。当往下滚的时候,这时候球体的Y比平面小了,所以这时候场景停住了。停住的原因是由于在Unity的Console窗体中的Error Pause选项被选中。个人认为这样更便于观察出错的那一刻的场景表现。

    假设关闭Error Pause又一次播放场景。假设出现抛异常后不会再暂停。

    我们来查看一下都报了什么错误。


    相信了解測试的同学都看出来了。Expected为我们的期望值,Actual为实际值。实际值小于期望值,所以抛异常了。


    集成測试:


    说完了断言组件就不得不提一下集成測试,正是由于能够抛出异常,所以断言组件和集成測试能够配合使用。

    我们来看一些场景ExampleABTests

    ExampleABTests这个案例我们想測试三件事:

    当角色足够近(触发碰撞)的时候,蜘蛛唤醒。走向角色

    当角色的距离不满足(没有触发碰撞)的时候,蜘蛛不会唤醒

    触发爆炸而且伤害角色

    所以场景中三个測试,所使用两个预制PlayerPrefab EnemySpider。

    一个是一个角色。

    另外一个预制是一个蜘蛛敌人。

    首先我们来看Test_PlayerReceivesDamageWhenSpiderExplodes这个測试,通过在Hierarchy下查看到除了两个预制另一个GameObject上面绑定着一个断言组件,

    断言所描写叙述的是2秒内还没有让HP低于75的话就算測试失败。

    PS:蜘蛛自爆须要一定的时间,通过測试发现蜘蛛爆炸大概须要4秒时间。


    我们来执行一下这个測试,点击Unity菜单条中的UnityTestTools。然后点击Integration Test Runner打开集成測试窗体,因为我们仅仅測试这一个測试,所以我们就选中Test_PlayerReceivesDamageWhenSpiderExplodes測试,然后点击窗体中的Run Selected,能够看到測试失败了。由于玩家的HP并没有在2秒内受到伤害,从下图能够看到HP并没有改变。依然是75,所以測试失败。


    我们改变一下断言中的时间把2秒设置为5秒,这样蜘蛛就有充分的时间来引爆,改动以后保存。我们再执行一次,这次能够看到蜘蛛爆炸把人物炸飞了而且HP也扣了。所以測试自然也通过了。


    其它两个測试:

    Test_SpiderSleepsWhenPlayerNotInRange---角色在蜘蛛可触发攻击的视野范围以外,确保它不会攻击玩家

    我们打开发现当中多了一个立方体上绑定着一个代码Call Testing。依据描写叙述能够知道当碰撞盒触发的时候则算是失败,失败则为假(False)。

    验证是通过假设蜘蛛触发了物体CubeCollisionFailure的碰撞器则说明測试失败。由于触发了说明它会跑向角色。这不是我们想要的,所以断言中我们採用了布尔类型,我们断言蜘蛛不会开启(不开启则为False)移动攻击控制器(跑向玩家并攻击)。測试证明它确实不会。由于断言的两个对象都为False。


    Test_SpiderWakesWhenPlayerInRange

    由于几乎相同所以我们就不再多说。
    玩家在蜘蛛的视野范围以内。蜘蛛醒来,開始朝着这名玩家。在蜘蛛和玩家之间有一个叫Testing.Succeed()的碰撞。

    当蜘蛛走向这个立方体的时候成功碰撞
    球员,踩上了触发器Trigger,測试通过。


    单元測试

    下载的插件中案例Sample.cs包括显示主要的NUnit使用方法演示样例。学习Nunit的同学能够前往http://www.36sign.com/nunit/setup.html,这个是中文的文档。相比起看英文easy的多。

    因为我更新到了Unity5.3,单元測试被集成到系统中,点击菜单条中的Windows找到Editor Test Runner就是单元測试工具了!

    官方的样例Sample.cs已经有了非常多的样例,由于文字太多不太好看,我们做一个简单的样例。

    在Asset下创建目录Editor。然后右键在目录下创建Editor Test C#Scripts,名字我们就默认的NewEditorTest就好了。

    代码例如以下,

    using UnityEngine;
    using UnityEditor;
    using NUnit.Framework;
    
    
    public class NewEditorTest {
    
        [Test]
        public void EditorTest()
        {
            int i = 2;
            int j = i + 1;
            Assert.AreEqual(3, j);
        }
    }
    事实上就是断言J是否等于3,我们打开单元測试窗体(Editor Test Runner)。能够看到里面就有我们刚刚输入的代码了我们执行一下,发现全绿了。通过。

    那这时候我们回到代码,把3改成4。能够看到抛异常了。例如以下图:


    理想的答案是4,可是J等于3呀。所以抛异常,我们接着改动代码。来測试一下已知的抛异常。

    using UnityEngine;
    using UnityEditor;
    using NUnit.Framework;
    using System;
    
    public class NewEditorTest {
    
        [Test]
        [ExpectedException(typeof(ArgumentException), ExpectedMessage = "expected message")]
        public void ExpectedExceptionTest()
        {
            throw new ArgumentException("expected message");
        }
    }
    
    通过測试也通过了,很多其它的须要同学们去学习Nunit才知道噢。


    測试输出XML

    最后我们来说说如何输出測试XML,我们打开场景ExampleABTests。

    这三个測试都是通过的。为了更直观,我们把Test_SpiderSleepsWhenPlayerNotInRange下的GameObject中的断言改为True,已知蜘蛛敌人是不会触发碰撞盒的。所以測试肯定是失败咯。

    我们点击菜单条中的Unity Test Tools--Platform Runner--Run On Platform


    我这里直接选择測试平台为Windows方便查看,点击build and run tests,程序会自己主动执行。而且执行測试。

    依据提示能够了解哪个场景出现故障,而且是哪一个GameObject,期望值是什么,实际值是什么。


    因为我刚才设置输出文档为项目的根目录目录。前往目录就能够看到了


    打开就能够看到刚才三个測试的结果报告以及平台和版本号以及时间和期望值与实际值和抛异常的位置。



    最后总结一下,Unity測试工具的长处把。

    通过几天的琢磨,这个工具的长处在于非常多地方不须要去编译不论什么一句代码便能够实现我们所须要的測试行为,比方这个函数所表现的是怪在不进入视野范围内是不会触发攻击的,可是却启用了攻击函数。这就证明了代码是有缺陷的。单元測试尽管小。可是把一个个模块分开来化繁为简,早一些发现问题,不至于在之后慌不择路,測试是一门非常深的学问,所想的东西甚至比开发所想的要很多其它,加油吧。




  • 相关阅读:
    wireshark 实用过滤表达式(针对ip、协议、端口、长度和内容)
    32:从1到n整数中1出现的次数
    31:连续子数组的最大和
    30:最小的K个数
    29:数组中出现次数超过一半的数字
    28:字符串的排列
    27:二叉搜索树与双向链表
    26:复杂链表的复制
    25:二叉树中和为某一个定值的路径
    24:二叉搜索树的后序遍历序列
  • 原文地址:https://www.cnblogs.com/slgkaifa/p/7345387.html
Copyright © 2020-2023  润新知