怎么使用unity测试游戏_使用Unity Test Runner测试测试驱动的开发

怎么使用unity测试游戏

Test-driven development (TDD) is the practice of writing automated tests for a piece of code before writing the code itself. In this blog post, I’m going to explain how my colleagues and I used TDD for making games (with code snippets), as well as what went well and what didn’t. TDD is not a fix-all, but we definitely learned a lot and became better developers as a result. We used Unity Test Runner in our project, which is a system for writing and executing NUnit tests in Unity.

测试驱动开发(TDD)是在编写代码本身之前为一段代码编写自动化测试的实践。 在这篇博客文章中，我将解释我和我的同事如何使用TDD制作游戏(带有代码片段)，以及什么做得好，什么没做。 TDD并不是万能的，但是我们无疑学到了很多东西，因此成为了更好的开发人员。 我们在项目中使用了Unity Test Runner ，该项目是一个用于在Unity中编写和执行NUnit测试的系统。

The usual workflow for TDD is as follows:

TDD的通常工作流程如下：

Following this workflow speeds up the process of refactoring code and making changes, because you can see straight away what has broken and why.

遵循此工作流程可以加快代码重构和更改的过程，因为您可以立即看到发生问题的原因以及原因。

You may wonder why we write the test before writing the code itself. This is because writing tests after writing the code can often lead to developers writing tests to make them pass. When you write a failing test first, you’re making sure that it fails for a good reason (such as not implementing the required functionality correctly), as well as ruling out false positives.

您可能想知道为什么我们在编写代码本身之前就编写测试。 这是因为在编写代码之后编写测试通常会导致开发人员编写测试以使其通过。 当您首先编写失败的测试时，您要确保它有充分的理由失败(例如未正确实现所需的功能)，并排除误报。

TDD is commonly used in software development, but it’s quite rare in game development.

TDD通常用于软件开发中，但在游戏开发中却很少见。

Last month, five people from different teams in Unity’s Release Engineering Group got together to look into making games using TDD. I’d heard before that some developers think they can’t have automated games with their game code, and they certainly couldn’t use TDD, so I wanted to see for myself.

上个月，Unity发行工程小组中来自不同团队的五个人聚在一起，探讨使用TDD制作游戏。 我之前曾听说过，有些开发人员认为他们无法使用其游戏代码来开发自动游戏，而且他们当然不能使用TDD，所以我想亲自看看。

We decided to make a few classic games – Pong, Snake, Asteroids, and Flappy Bird. The benefit of this was that we didn’t need to spend any time designing gameplay, because we already had a rough idea of how everything would come together (or so we thought).

我们决定制作一些经典游戏-Pong，Snake，Asteroids和Flappy Bird。 这样做的好处是我们不需要花任何时间来设计游戏玩法，因为我们已经对所有东西如何组合在一起有了一个粗略的想法(或者我们认为)。

While we knew how each game would work, we still had to really drill down into the concepts so we could know how to structure our tests. With the example of Pong, I knew that a paddle should move… But what even is a paddle? Every idea had to be broken down.

虽然我们知道每个游戏的工作方式，但仍然必须深入研究这些概念，以便我们知道如何构建测试。 以乒乓球为例，我知道一个桨应该运动……但是一个桨又是什么？ 每个想法都必须分解。

We broke a paddle in Pong down to the following attributes:

我们在Pong中将桨划破了以下属性：

Doing this gave us a good starting point for writing tests. For example:

这样做为我们编写测试提供了良好的起点。 例如：

[Test] public void AtLeastOnePaddleIsSuccesfullyCreated() { GameObject[] paddles = CreatePaddles(); // Assert that the paddles object exists Assert.IsNotNull(paddles); } [Test] public void TwoPaddlesAreSuccesfullyCreated() { GameObject[] paddles = CreatePaddles(); // Assert that the number of paddles equals 2 Assert.AreEqual(2, paddles.Length); } [Test] public void AtLeastOnePaddleIsSuccesfullyCreated() { GameObject[] paddles = CreatePaddles(); // Assert that the paddles object exists Assert.IsNotNull(paddles); } [Test] public void TwoPaddlesAreSuccesfullyCreated() { GameObject[] paddles = CreatePaddles(); // Assert that the number of paddles equals 2 Assert.AreEqual(2, paddles.Length); }

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

[Test]