Introducción a las pruebas unitarias en Unity

¿Tienes curiosidad por saber cómo funcionan las pruebas unitarias en Unity? ¿No está seguro de qué prueba de unidad es en general? Si respondiste positivamente a estas preguntas, entonces este tutorial te será útil. De él aprenderá lo siguiente sobre las pruebas unitarias:

• Que es esto
• Su beneficio
• Ventajas y desventajas.
• Cómo funciona en Unity usando Test Runner
• Cómo escribir y ejecutar pruebas unitarias que serán probadas

Nota : este tutorial asume que está familiarizado con el lenguaje C # y los conceptos básicos del desarrollo en Unity. Si es nuevo en Unity, consulte primero los otros tutoriales en este motor .

¿Qué es una prueba unitaria?

Antes de profundizar en el código, es importante comprender claramente qué es la prueba de unidad. En pocas palabras, las pruebas unitarias son pruebas ... unidades.

La prueba de la unidad (idealmente) está diseñada para probar una unidad de código separada. La composición de una "unidad" puede variar, pero es importante recordar que las pruebas unitarias deben probar exactamente un "elemento" a la vez.

Es necesario crear pruebas unitarias para verificar que un pequeño fragmento lógico de código en un escenario particular se ejecute exactamente como se espera. Esto puede ser difícil de entender antes de comenzar a escribir sus propias pruebas unitarias, así que veamos un ejemplo:

Ha escrito un método que permite al usuario ingresar un nombre. El método se escribe para que no se permitan números en el nombre, y el nombre en sí mismo puede constar de solo diez caracteres o menos. Su método intercepta la pulsación de tecla de cada tecla y agrega el carácter correspondiente al campo de name :

 public string name = "" public void UpdateNameWithCharacter(char: character) { // 1 if (!Char.IsLetter(char)) { return; } // 2 if (name.Length > 10) { return; } // 3 name += character; } 

¿Qué está pasando aquí?

1. Si el carácter no es una letra, entonces el código sale previamente de la función y no agrega el carácter a la cadena.
2. Si el nombre tiene diez o más caracteres, el código no permite al usuario agregar otro carácter.
3. Si se pasan estas dos comprobaciones, el código agrega un carácter al final del nombre.

Esta unidad se puede probar, ya que es un "módulo" del trabajo realizado. Las pruebas unitarias imponen la lógica del método.

Ejemplo de prueba de unidad

¿Cómo escribimos pruebas unitarias para el método UpdateNameWithCharacter ?

Antes de comenzar a implementar estas pruebas unitarias, debemos considerar cuidadosamente lo que hacen estas pruebas y encontrar nombres para ellas.

Eche un vistazo a los ejemplos de nombres de prueba de unidad a continuación. De los nombres debe quedar claro que verifican:

UpdateNameDoesntAllowCharacterAddingToNameIfNameIsTenOrMoreCharactersInLength

UpdateNameAllowsLettersToBeAddedToName

UpdateNameDoesntAllowNonLettersToBeAddedToName

A partir de estos nombres de métodos de prueba, vemos que realmente verificamos si la "unidad" de trabajo se UpdateNameWithCharacter mediante el método UpdateNameWithCharacter . Estos nombres de prueba pueden parecer demasiado largos y detallados, pero es bueno para nosotros.

Cada prueba unitaria que escriba es parte de un conjunto de pruebas. El conjunto de pruebas contiene todas las pruebas unitarias relacionadas con el grupo lógico funcional (por ejemplo, "pruebas de unidades de batalla"). Si alguna prueba del kit falla, entonces todo el conjunto de pruebas falla.

Lanzamiento del juego

Abra el proyecto Crashteroids Starter (puede descargarlo desde aquí ) y luego abra la escena del juego desde la carpeta Assets / RW / Scenes .


Haga clic en Jugar para iniciar Crashteroids, y luego haga clic en el botón Iniciar juego . Mueve la nave espacial con las flechas izquierda y derecha del teclado.

Para disparar un rayo láser, presione la barra espaciadora . Si el rayo golpea el asteroide, la puntuación aumentará en uno. Si un asteroide choca con un barco, el barco explota y el juego termina (con la posibilidad de comenzar de nuevo).


Intenta jugar un poco y asegúrate de que después de la colisión del asteroide con la nave aparezca la inscripción Game Over.

Comenzando con Unity Test Runner

Ahora que sabemos cómo funciona el juego, es hora de escribir pruebas unitarias para verificar que todo funcione como debería. Por lo tanto, si usted (u otra persona) decide actualizar el juego, estará seguro de que la actualización no romperá nada de lo que funcionó antes.

Para escribir pruebas, primero debe aprender sobre Unity Test Runner. Test Runner le permite ejecutar pruebas y verificar si pasan con éxito. Para abrir Unity Test Runner, seleccione Ventana ▸ General ▸ Test Runner .


Después de que Test Runner se abra en una nueva ventana, puede simplificar su vida haciendo clic en la ventana de Test Runner y arrastrándola al lugar junto a la ventana de Scene.

Preparación de NUnit y carpetas de prueba

Test Runner es una función de prueba unitaria proporcionada por Unity, pero utiliza el marco NUnit . Cuando comience a trabajar con pruebas unitarias más en serio, le recomiendo estudiar la wiki en NUnit para obtener más información. En este artículo se analizará todo lo que necesita por primera vez.

Para ejecutar las pruebas, primero debemos crear una carpeta de prueba en la que se almacenarán las clases de prueba.

En la ventana Proyecto, seleccione la carpeta RW . Eche un vistazo a la ventana Test Runner y asegúrese de que PlayMode esté seleccionado.

Haga clic en el botón llamado Crear carpeta de ensamblaje de prueba de PlayMode . Verá aparecer una nueva carpeta en la carpeta RW. Estamos satisfechos con las pruebas de nombre estándar, por lo que puede presionar Entrar .


Tal vez se pregunte cuáles son estas dos pestañas diferentes dentro de Test Runner.

La pestaña PlayMode se usa para las pruebas realizadas en el modo Play (cuando el juego se ejecuta en tiempo real). Las pruebas en la pestaña EditMode se ejecutan fuera del modo Play, lo cual es conveniente para probar cosas como comportamientos personalizados en el Inspector.

En este tutorial, cubriremos las pruebas de PlayMode. Pero cuando se sienta cómodo, puede intentar experimentar con las pruebas en EditMode. Cuando trabaje con Test Runner en este tutorial, asegúrese siempre de que la pestaña PlayMode esté seleccionada .

¿Qué hay en el conjunto de pruebas?

Como aprendimos anteriormente, una prueba unitaria es una función que prueba el comportamiento de un pequeño fragmento de código específico. Dado que la prueba unitaria es un método, para ejecutarla, debe estar en el archivo de clase.

Test Runner omite todos los archivos de clase de prueba y realiza pruebas unitarias a partir de ellos. Un archivo de clase que contiene pruebas unitarias se denomina conjunto de pruebas.

En el conjunto de pruebas, subdividimos lógicamente nuestras pruebas. Debemos separar el código de prueba en conjuntos lógicos separados (por ejemplo, un conjunto de pruebas para física y un conjunto separado para batalla). En este tutorial solo necesitamos un conjunto de pruebas, y es hora de crear una.

Preparación de un conjunto de prueba y conjunto de pruebas

Seleccione la carpeta Pruebas y, en la ventana Test Runner , haga clic en el botón Crear secuencia de comandos de prueba en la carpeta actual . Nombre el nuevo archivo TestSuite .


Además del nuevo archivo C #, el motor de Unity también crea otro archivo llamado Tests.asmdef . Este es el archivo de definición de ensamblaje , que se utiliza para mostrar a Unity dónde están las dependencias del archivo de prueba. Esto es necesario porque el código de la aplicación terminada está contenido por separado del código de prueba.

Si tiene una situación en la que Unity no puede encontrar archivos de prueba o pruebas, asegúrese de que haya un archivo de definición de ensamblaje que incluya su conjunto de pruebas. El siguiente paso es configurarlo.

Para que el código de prueba tenga acceso a las clases de juego, crearemos un ensamblaje del código de clase y estableceremos el enlace en el ensamblaje de Pruebas. Haga clic en la carpeta Scripts para seleccionarlo. Haga clic derecho en esta carpeta y seleccione Crear ▸ Definición de ensamblaje .


Denomine el archivo GameAssembly .


Haga clic en la carpeta Pruebas y luego en el archivo de definición de compilación Pruebas . En el Inspector, haga clic en el botón más debajo del encabezado Referencias de definición de ensamblaje .


Verá el campo Falta referencia . Haga clic en el punto al lado de este campo para abrir la ventana de selección. Seleccione el archivo GameAssembly .


Debería ver el archivo de ensamblaje GameAssembly en la sección de enlaces. Haga clic en el botón Aplicar para guardar estos cambios.


Si no sigue estos pasos, no podrá hacer referencia a los archivos de clase del juego dentro de los archivos de prueba de la unidad. Después de lidiar con esto, puede continuar con el código.

Escribimos la primera prueba unitaria

Haga doble clic en el script TestSuite para abrirlo en el editor de código. Reemplace todo el código con esto:

 using UnityEngine; using UnityEngine.TestTools; using NUnit.Framework; using System.Collections; public class TestSuite { } 

¿Qué pruebas necesitamos escribir? Honestamente, incluso en un juego pequeño como Crashteroids, puedes escribir bastantes pruebas para verificar que todo funcione como debería. En este tutorial, nos restringimos solo a áreas clave: reconocimiento de colisión y mecánica básica del juego.

Nota : cuando se trata de escribir pruebas unitarias de un producto a nivel de producción, debe pagar el tiempo suficiente para tener en cuenta todos los casos límite que deben probarse en todas las áreas del código.

Como primera prueba, es bueno comprobar si los asteroides realmente se están moviendo hacia abajo. ¡Será difícil para ellos chocar con la nave si se alejan de ella! Agregue el siguiente método y variable privada al script TestSuite :

 private Game game; // 1 [UnityTest] public IEnumerator AsteroidsMoveDown() { // 2 GameObject gameGameObject = MonoBehaviour.Instantiate(Resources.Load<GameObject>("Prefabs/Game")); game = gameGameObject.GetComponent<Game>(); // 3 GameObject asteroid = game.GetSpawner().SpawnAsteroid(); // 4 float initialYPos = asteroid.transform.position.y; // 5 yield return new WaitForSeconds(0.1f); // 6 Assert.Less(asteroid.transform.position.y, initialYPos); // 7 Object.Destroy(game.gameObject); } 

Solo hay unas pocas líneas de código, pero hacen muchas cosas. Entonces detengámonos y tratemos con cada parte:

1. Este es un atributo . Los atributos definen comportamientos específicos del compilador. Este atributo le dice al compilador de Unity que el código es una prueba unitaria. Debido a esto, aparecerá en el Test Runner cuando comience las pruebas.
2. Crea una instancia de Juego. Todo lo demás está incrustado en el juego, por lo que cuando lo creamos, contendrá todo lo que necesita ser probado. En un entorno de producción, lo más probable es que todos los elementos no estén dentro del mismo prefabricado. Por lo tanto, deberá recrear todos los objetos necesarios en la escena.
3. Aquí creamos un asteroide para que podamos monitorear si se está moviendo. El método SpawnAsteroid devuelve una instancia del asteroide creado. El componente Asteroide tiene un método Move (si tiene curiosidad sobre cómo funciona el movimiento, puede echar un vistazo a la secuencia de comandos Asteroid dentro de RW / Scripts ).
4. El seguimiento de la posición inicial es necesario para asegurarse de que el asteroide se haya movido hacia abajo.
5. Todas las pruebas unitarias de Unity son rutinas, por lo que debe agregar un retorno suave. También agregamos un paso de tiempo de 0.1 segundos para simular el paso del tiempo por el cual se suponía que el asteroide debía moverse hacia abajo. Si no necesita simular un paso de tiempo, puede devolver nulo.
6. Esta es la etapa de afirmación , en la que afirmamos que la posición del asteroide es menor que la posición inicial (es decir, se ha movido hacia abajo). Comprender las afirmaciones es una parte importante de las pruebas unitarias, y NUnit proporciona varios métodos de afirmación. Aprobar o no aprobar el examen está determinado por esta línea.
7. Por supuesto, nadie lo regañará por el desorden que queda después de completar las pruebas, pero otras pruebas pueden fallar debido a eso. Siempre es importante limpiar (eliminar o restablecer) el código después de la prueba de la unidad, de modo que cuando ejecute la próxima prueba de la unidad no queden artefactos que puedan afectar esta prueba. Es suficiente para nosotros simplemente eliminar el objeto del juego, porque para cada prueba creamos una instancia completamente nueva del juego.

Pasando pruebas

Bueno, escribiste tu primera prueba unitaria, pero ¿cómo sabes si funciona? Por supuesto, con Test Runner! En la ventana Test Runner, expanda todas las líneas con flechas. Debería ver la prueba AsteroidsMoveDown en la lista con círculos grises:


Un círculo gris indica que la prueba aún no se ha completado. Si la prueba se inició y pasó, se muestra una flecha verde al lado. Si la prueba falla, se mostrará una X roja junto a ella. Ejecute la prueba haciendo clic en el botón Ejecutar todo .


Esto creará una escena temporal y ejecutará la prueba. Al finalizar, debería ver que la prueba pasó.


Has escrito con éxito tu primera prueba unitaria indicando que los asteroides creados se están moviendo hacia abajo.

Nota : antes de comenzar a escribir sus propias pruebas unitarias, debe comprender la implementación que está probando. Si tiene curiosidad por saber cómo funciona la lógica que está probando, estudie el código en la carpeta RW / Scripts .

Usando pruebas de integración

Antes de profundizar en el agujero del conejo de las pruebas unitarias, es hora de decir qué son las pruebas de integración y en qué se diferencian de las pruebas unitarias.

Las pruebas de integración son pruebas que verifican cómo funcionan juntos los "módulos" del código. "Módulo" es otro término difuso. Una diferencia importante es que las pruebas de integración deben probar el funcionamiento del software en la producción real (es decir, cuando un jugador realmente juega un juego).


Digamos que hiciste un juego de batalla donde un jugador mata monstruos. Puedes crear una prueba de integración para asegurarte de que cuando un jugador mata a 100 enemigos, se abre un logro ("Logro").

Esta prueba afectará a varios módulos de código. Lo más probable es que se trate del motor físico (reconocimiento de colisiones), despachadores enemigos (que controlan la salud del enemigo y procesan daños, así como también pasan a otros eventos relacionados) y un rastreador de eventos que rastrea todos los eventos disparados (por ejemplo, "el monstruo es asesinado"). Luego, cuando llegue el momento de desbloquear el logro, puede llamar al administrador de logros.

La prueba de integración simulará al jugador matando a 100 monstruos y verificará si el logro está desbloqueado. Es muy diferente de la prueba unitaria porque prueba componentes de código grandes que funcionan juntos.

En este tutorial, no estudiaremos las pruebas de integración, pero esto debería mostrar la diferencia entre la unidad de trabajo (y por qué se está probando la unidad) y el módulo del código (y por qué se está probando la integración).

Agregar una prueba a un conjunto de pruebas

La próxima prueba probará el final del juego cuando la nave colisiona con un asteroide. Con TestSuite abierto en el editor de código, agregue la prueba que se muestra a continuación en la primera prueba unitaria y guarde el archivo:

 [UnityTest] public IEnumerator GameOverOccursOnAsteroidCollision() { GameObject gameGameObject = MonoBehaviour.Instantiate(Resources.Load<GameObject>("Prefabs/Game")); Game game = gameGameObject.GetComponent<Game>(); GameObject asteroid = game.GetSpawner().SpawnAsteroid(); //1 asteroid.transform.position = game.GetShip().transform.position; //2 yield return new WaitForSeconds(0.1f); //3 Assert.True(game.isGameOver); Object.Destroy(game.gameObject); } 

Ya vimos la mayor parte de este código en la prueba anterior, pero hay algunas diferencias:

1. Obligamos al asteroide y a la nave a colisionar, dando claramente al asteroide la misma posición que la nave. Esto creará una colisión de sus hitboxes y conducirá al final del juego. Si tiene curiosidad sobre cómo funciona este código, eche un vistazo a los archivos Ship , Game y Asteroid en la carpeta Scripts.
2. Es necesario un paso de tiempo para que se active el evento Colisión del motor físico, por lo que se devuelve un retraso de 0.1 segundos.
3. Esta afirmación es verdadera y verifica que el indicador gameOver en el script del juego es verdadero. La bandera se vuelve verdadera durante la operación del juego, cuando se destruye el barco, es decir, probamos para asegurarnos de que se establece en verdadero después de la destrucción del barco.

Regrese a la ventana Test Runner y verá que una nueva prueba de unidad ha aparecido allí.


Esta vez ejecutaremos este en lugar del conjunto de pruebas completo. Haga clic en GameOverOccursOnAsteroidCollision , y luego en el botón Ejecutar seleccionado .


Y listo, pasamos otra prueba.

Etapas de sintonización y destrucción

Es posible que haya notado que en nuestras dos pruebas hay un código que se repite: dónde se crea el objeto Juego y dónde se establece un enlace al script del Juego:

 GameObject gameGameObject = MonoBehaviour.Instantiate(Resources.Load<GameObject>("Prefabs/Game")); game = gameGameObject.GetComponent<Game>(); 

También notarás que hay una repetición en la destrucción del objeto Juego:

 Object.Destroy(game.gameObject); 

Al probar esto sucede muy a menudo. Cuando se trata de ejecutar pruebas unitarias, en realidad hay dos fases: la fase de configuración y la fase de desmontaje .

Todo el código dentro del método de configuración se ejecutará antes de la prueba de la unidad (en este conjunto), y todo el código dentro del método Tear Down se ejecutará después de la prueba de la unidad (en este conjunto).

Es hora de simplificar nuestras vidas moviendo la configuración y desmontando el código a métodos especiales. Abra el editor de código y agregue el siguiente código al comienzo del archivo TestSuite , justo antes del primer atributo [UnityTest]:

 [SetUp] public void Setup() { GameObject gameGameObject = MonoBehaviour.Instantiate(Resources.Load<GameObject>("Prefabs/Game")); game = gameGameObject.GetComponent<Game>(); } 

El atributo SetUp indica que se llama a este método antes de SetUp cada prueba.

Luego agregue el siguiente método y guarde el archivo:

 [TearDown] public void Teardown() { Object.Destroy(game.gameObject); } 

El atributo TearDown indica que se llama a este método después de TearDown cada prueba.

Una vez preparado el código de configuración y destrucción, elimine las líneas de código que están presentes en estos métodos y reemplácelas con llamadas a los métodos correspondientes. Después de eso, el código se verá así:

 public class TestSuite { private Game game; [SetUp] public void Setup() { GameObject gameGameObject = MonoBehaviour.Instantiate(Resources.Load<GameObject>("Prefabs/Game")); game = gameGameObject.GetComponent<Game>(); } [TearDown] public void Teardown() { Object.Destroy(game.gameObject); } [UnityTest] public IEnumerator AsteroidsMoveDown() { GameObject asteroid = game.GetSpawner().SpawnAsteroid(); float initialYPos = asteroid.transform.position.y; yield return new WaitForSeconds(0.1f); Assert.Less(asteroid.transform.position.y, initialYPos); } [UnityTest] public IEnumerator GameOverOccursOnAsteroidCollision() { GameObject asteroid = game.GetSpawner().SpawnAsteroid(); asteroid.transform.position = game.GetShip().transform.position; yield return new WaitForSeconds(0.1f); Assert.True(game.isGameOver); } } 

Prueba de juego terminado y disparo con láser

Una vez preparados los métodos de ajuste y destrucción que simplifican nuestras vidas, podemos comenzar a agregar nuevas pruebas en las que se utilizan. La siguiente prueba es verificar que cuando un jugador hace clic en Nuevo juego , el valor de gameOver bool no es cierto. Agregue dicha prueba al final del archivo y guárdela:

 [UnityTest] public IEnumerator NewGameRestartsGame() { //1 game.isGameOver = true; game.NewGame(); //2 Assert.False(game.isGameOver); yield return null; } 

Esto ya debería parecerte familiar, pero vale la pena mencionar lo siguiente:

1. Este fragmento de código prepara esta prueba para que el gameOver booleano gameOver sea ​​verdadero. Al llamar al método NewGame , nuevamente debe establecer el indicador en false .
2. Aquí argumentamos que bool isGameOver es false , lo que debería ser cierto cuando se invoca un nuevo juego.

Regrese a Test Runner y debería ver que hay una nueva prueba NewGameRestartsGame . Ejecute esta prueba, como lo hicimos antes, y verá que se ejecuta con éxito:

Declaración de rayo láser

La siguiente prueba es agregar la prueba de que el rayo láser disparado por la nave está volando (similar a la primera prueba de unidad que escribimos). Abra el archivo TestSuite en el editor. Agregue el siguiente método y guarde el archivo:

 [UnityTest] public IEnumerator LaserMovesUp() { // 1 GameObject laser = game.GetShip().SpawnLaser(); // 2 float initialYPos = laser.transform.position.y; yield return new WaitForSeconds(0.1f); // 3 Assert.Greater(laser.transform.position.y, initialYPos); } 

Esto es lo que hace este código:

1. Obtiene un enlace al rayo láser generado emitido desde la nave.
2. La posición inicial se registra para que podamos verificar que se está moviendo hacia arriba.
3. Esta declaración es consistente con la declaración de la prueba de la unidad AsteroidsMoveDown , solo que ahora afirmamos que el valor es mayor (es decir, el láser se mueve hacia arriba).

Guarde el archivo y regrese a Test Runner. Ejecute la prueba LaserMovesUp y observe cómo pasa:


Ahora ya debe comenzar a comprender cómo funciona todo, por lo que es hora de agregar las dos últimas pruebas y completar el tutorial.

Verificando que el láser destruya los asteroides

A continuación, nos aseguraremos de que cuando se golpee, el láser destruya el asteroide. Abra el editor y agregue la siguiente prueba al final de TestSuite , y luego guarde el archivo:

 [UnityTest] public IEnumerator LaserDestroysAsteroid() { // 1 GameObject asteroid = game.GetSpawner().SpawnAsteroid(); asteroid.transform.position = Vector3.zero; GameObject laser = game.GetShip().SpawnLaser(); laser.transform.position = Vector3.zero; yield return new WaitForSeconds(0.1f); // 2 UnityEngine.Assertions.Assert.IsNull(asteroid); } 

Así es como funciona:

1. Creamos un asteroide y un rayo láser, y les asignamos la misma posición para provocar una colisión.
2. Esta es una prueba especial con una distinción importante. ¿Ves que utilizamos explícitamente UnityEngine.Assertions para esta prueba ? Esto se debe a que Unity tiene una clase nula especial que es diferente de la clase nula "regular". Una instrucción de marco NUnit Assert.IsNull() no funcionará en las comprobaciones de Unity para nulo. Al verificar nulo en Unity, debe usar explícitamente UnityEngine.Assertions.Assert, no Assert from NUnit.

Regrese a Test Runner y ejecute una nueva prueba. Verá un icono verde que nos agrada.

Probar o no evaluar: esa es la pregunta

La decisión de apegarse a las pruebas unitarias no es una decisión fácil y no debe tomarse a la ligera. Sin embargo, los beneficios de las pruebas merecen la pena. Hay incluso una metodología de desarrollo, llamado desarrollo basado en pruebas (Test Driven Development, TDD).

Trabajando dentro del marco de TDD, usted escribe pruebas antes de escribir la lógica de la aplicación. Primero, crea pruebas, asegúrese de que el programa no las pase y luego escriba solo el código diseñado para pasar las pruebas. Este puede ser un enfoque muy diferente a la codificación, pero asegura que usted escriba el código de manera adecuada para las pruebas.

Tenga esto en cuenta cuando comience a trabajar en su próximo proyecto. Pero por ahora, es hora de escribir sus propias pruebas unitarias, para las cuales necesita un juego que le hemos proporcionado.

: — , . , . «» , , . , . , . , , .

Las pruebas pueden ser una gran inversión, así que considere las ventajas y desventajas de agregar pruebas unitarias a su proyecto:

Ventajas de las pruebas unitarias

Las pruebas unitarias tienen muchas ventajas importantes, que incluyen las siguientes:

• Da confianza de que el método se comporta como se esperaba.
• Sirve como documentación para nuevas personas que estudian la base del código (las pruebas unitarias son excelentes para la enseñanza).
• Te hace escribir código de manera comprobable.
• Permite aislar y corregir errores más rápido.
• No permite actualizaciones futuras para agregar nuevos errores al antiguo código de trabajo (se denominan errores de regresión).

Desventajas de las pruebas unitarias

Sin embargo, es posible que no tenga tiempo o presupuesto para realizar pruebas unitarias. Estas son sus desventajas a tener en cuenta:

• Escribir pruebas puede llevar más tiempo que el código en sí.
• .
• .
• , .
• , -.
• ( ), .
• - .
• UI .
• .
• .

,

Es hora de escribir la última prueba. Abra el editor de código, agregue el siguiente código al final del archivo TestSuite y guárdelo:

 [UnityTest] public IEnumerator DestroyedAsteroidRaisesScore() { // 1 GameObject asteroid = game.GetSpawner().SpawnAsteroid(); asteroid.transform.position = Vector3.zero; GameObject laser = game.GetShip().SpawnLaser(); laser.transform.position = Vector3.zero; yield return new WaitForSeconds(0.1f); // 2 Assert.AreEqual(game.score, 1); } 

Esta es una prueba importante, verificando que cuando un jugador destruye un asteroide, la puntuación aumenta. En esto consiste:

1. Creamos un asteroide y un rayo láser, y los colocamos en una posición. Debido a esto, surge una colisión que desencadena un aumento en la puntuación.
2. La afirmación de que game.score ahora es 1 (y no 0, como era al principio).

Guarde el código y regrese a Test Runner para ejecutar esta última prueba y ver si se ejecuta el juego:


Impresionante! Todas las pruebas pasaron.

¿A dónde ir después?

En el artículo examinamos una gran cantidad de información. Si desea comparar su trabajo con el proyecto final, mírelo en el archivo , cuyo enlace también se indica al comienzo del artículo.

En este tutorial, aprendió qué son las pruebas unitarias y cómo escribirlas en Unity. Además, escribió seis pruebas unitarias que aprobaron el código con éxito y se familiarizó con algunos de los pros y los contras de las pruebas unitarias.

¿Te sientes seguro? Entonces puedes escribir muchas más pruebas. Examine los archivos de clase del juego e intente escribir pruebas unitarias para otras partes del código. Considere agregar pruebas para los siguientes escenarios:

• Cada tipo de asteroide cuando tocas la nave conduce al final del juego.
• Comenzar un nuevo juego restablece el puntaje.
• El movimiento hacia la izquierda y hacia la derecha de la nave funciona correctamente.

Si desea aumentar su conocimiento de las pruebas unitarias, entonces vale la pena explorar la implementación de dependencias y marcos para trabajar con objetos simulados . Esto puede simplificar enormemente la configuración de la prueba.

Lea también la documentación de NUnit para obtener más información sobre el marco de NUnit.

Y siéntase libre de compartir sus pensamientos y preguntas en los foros.

¡Pruebas exitosas!