unit-testing

#unit-testing
Tabla de contenido
Acerca de 1

Capítulo 1: Comenzando con la prueba unitaria 2

Observaciones 2

Versiones 2

Examples 2

Una prueba unitaria básica. 2

Una prueba unitaria con dependencia tachonada. 3

Una prueba de unidad con un espía (prueba de interacción) 3

Prueba simple de Java + JUnit 4

Prueba de unidad con parámetros usando NUnit y C # 5

Una prueba básica de unidad de pitón. 6

Una prueba XUnit con parámetros. 6

Capítulo 2: Guía de pruebas unitarias en Visual Studio para C # 8

Introducción 8

Examples 8

Creando un proyecto de prueba unitaria 8

Añadiendo la referencia a la aplicación que quieres probar. 9

Dos métodos para crear pruebas unitarias. 10

Método 1 10

Método 2 11

Ejecutando pruebas unitarias dentro de Visual Studio 12

Ejecutando análisis de cobertura de código dentro de Visual Studio 13

Capítulo 3: Inyección de dependencia 16

Observaciones 16

Examples 17

Inyección Constructor 17

Inyección de propiedad 17

Método de inyección 18

Contenedores / Marcos DI 18

Capítulo 4: Las reglas generales para la prueba unitaria para todos los idiomas. 21
 Introducción 21

Observaciones 21

¿Qué es la prueba unitaria? 21

¿Qué es una unidad? 21

La diferencia entre las pruebas unitarias y las pruebas de integración. 21

El SetUp y TearDown 21

Como lidiar con las dependencias. 22

Clases falsas 22

¿Por qué pruebas de unidad? 22

Reglas generales para la prueba unitaria. 23

Examples 25

Ejemplo de prueba unitaria simple en C # 25

Capítulo 5: Prueba de dobles 27

Observaciones 27

Examples 27

Usando un talón para suministrar respuestas enlatadas 27

Usando un marco de burla como un trozo 28

Usando un marco de burla para validar el comportamiento 28

Capítulo 6: Pruebas unitarias de Loops (Java) 30

Introducción 30

Examples 30

Prueba de un solo bucle 30

Prueba de bucles anidados 31

Prueba de bucles concatenados 32

Capítulo 7: Pruebas Unitarias: Mejores Prácticas 33

Introducción 33

Examples 33

Buen nombramiento 33

De lo simple a lo complejo. 34

Concepto de MakeSut 34

Capítulo 8: Tipos de aserción 36

 Examples 36

Verificando un valor devuelto 36

Pruebas basadas en el estado 36

Verificando que una excepción es lanzada 36

Creditos 38
Acerca de
You can share this PDF with anyone you feel could benefit from it, downloaded the latest version
from: unit-testing

It is an unofficial and free unit-testing ebook created for educational purposes. All the content is
extracted from Stack Overflow Documentation, which is written by many hardworking individuals at
Stack Overflow. It is neither affiliated with Stack Overflow nor official unit-testing.

The content is released under Creative Commons BY-SA, and the list of contributors to each
chapter are provided in the credits section at the end of this book. Images may be copyright of
their respective owners unless otherwise specified. All trademarks and registered trademarks are
the property of their respective company owners.

Use the content presented in this book at your own risk; it is not guaranteed to be correct nor
accurate, please send your feedback and corrections to [email protected]

https://riptutorial.com/es/home 1
Capítulo 1: Comenzando con la prueba
unitaria
Observaciones
La prueba de unidad describe el proceso de prueba de unidades de código individuales aisladas
del sistema del que forman parte. Lo que constituye una unidad puede variar de un sistema a
otro, desde un método individual hasta un grupo de clases estrechamente relacionadas o un
módulo.

La unidad está aislada de sus dependencias utilizando la prueba de dobles cuando es necesario y
la configuración en un estado conocido. Su comportamiento en reacción a los estímulos (llamadas
a métodos, eventos, datos simulados) se compara con el comportamiento esperado.

Las pruebas unitarias de sistemas completos se pueden realizar utilizando arneses

personalizados de prueba, sin embargo, se han escrito muchos marcos de prueba para ayudar a
agilizar el proceso y cuidar gran parte de las tareas rutinarias, repetitivas y mundanas. Esto
permite a los desarrolladores concentrarse en lo que quieren probar.

Cuando un proyecto tiene suficientes pruebas unitarias, cualquier modificación para agregar una
nueva funcionalidad o realizar una refactorización de código se puede hacer fácilmente
verificando que todo funciona como antes.

La cobertura del código , normalmente expresada como un porcentaje, es la métrica típica

utilizada para mostrar qué parte del código en un sistema está cubierto por las pruebas unitarias;
tenga en cuenta que no hay una regla estricta y rápida sobre qué tan alto debe ser, pero
generalmente se acepta que cuanto más alto, mejor.

El desarrollo dirigido por pruebas (TDD) es un principio que especifica que un desarrollador debe
comenzar a codificar escribiendo una prueba de unidad que falla y solo entonces escribe el
código de producción que hace que la prueba pase. Al practicar TDD, se puede decir que las
pruebas en sí mismas son el primer consumidor del código que se está creando; por lo tanto,
ayudan a auditar y dirigir el diseño del código para que sea tan fácil de usar y tan robusto como
sea posible.

Versiones
La prueba de unidad es un concepto que no tiene números de versión.

Examples
Una prueba unitaria básica.

En su forma más simple, una prueba de unidad consta de tres etapas:

https://riptutorial.com/es/home 2
 • Preparar el entorno para la prueba.
• Ejecutar el código a probar.
• Validar el comportamiento esperado coincide con el comportamiento observado.

Estas tres etapas a menudo se llaman 'Arrange-Act-Assert', o 'Given-When-Then'.

A continuación se muestra un ejemplo en C # que usa el marco NUnit .

[TestFixture]
public CalculatorTest
{
[Test]
public void Add_PassSevenAndThree_ExpectTen()
{
// Arrange - setup environment
var systemUnderTest = new Calculator();

// Act - Call system under test

var calculatedSum = systemUnderTest.Add(7, 3);

// Assert - Validate expected result

Assert.AreEqual(10, calculatedSum);
}
}

Donde sea necesario, una cuarta etapa de limpieza opcional se pone en orden.

Una prueba unitaria con dependencia tachonada.

Las buenas pruebas unitarias son independientes, pero el código a menudo tiene dependencias.
Usamos varios tipos de pruebas para eliminar las dependencias para las pruebas. Una de las
pruebas más sencillas es un trozo. Esta es una función con un valor de retorno codificado en
lugar de la dependencia del mundo real.

// Test that oneDayFromNow returns a value 24*60*60 seconds later than current time

let systemUnderTest = new FortuneTeller() // Arrange - setup environment

systemUnderTest.setNow(() => {return 10000}) // inject a stub which will
// return 10000 as the result

let actual = systemUnderTest.oneDayFromNow() // Act - Call system under test

assert.equals(actual, 10000 + 24 * 60 * 60) // Assert - Validate expected result

En el código de producción, oneDayFromNow llamaría a Date.now (), pero eso generaría pruebas
inconsistentes y poco confiables. Así que aquí lo apagamos.

Una prueba de unidad con un espía (prueba de interacción)

Las pruebas unitarias clásicas prueban el estado , pero puede ser imposible probar correctamente
los métodos cuyo comportamiento depende de otras clases a través del estado. Probamos estos
métodos a través de pruebas de interacción , que verifican que el sistema bajo prueba llame
correctamente a sus colaboradores. Dado que los colaboradores tienen sus propias pruebas de

https://riptutorial.com/es/home 3
unidad, esto es suficiente, y en realidad es una mejor prueba de la responsabilidad real del
método probado. No probamos que este método devuelva un resultado particular a partir de una
entrada, sino que llame a su (s) colaborador (es) correctamente.

// Test that squareOfDouble invokes square() with the doubled value

let systemUnderTest = new Calculator() // Arrange - setup environment

let square = spy()
systemUnderTest.setSquare(square) // inject a spy

let actual = systemUnderTest.squareOfDouble(3) // Act - Call system under test

assert(square.calledWith(6)) // Assert - Validate expected interaction

Prueba simple de Java + JUnit

JUnit es el marco de pruebas líder utilizado para probar código Java.

La clase bajo prueba modela una cuenta bancaria simple, que cobra una multa cuando se
sobregira.

public class BankAccount {

private int balance;

public BankAccount(int i){

balance = i;
}

public BankAccount(){
balance = 0;
}

public int getBalance(){

return balance;
}

public void deposit(int i){

balance += i;
}

public void withdraw(int i){

balance -= i;
if (balance < 0){
balance -= 10; // penalty if overdrawn
}
}
}

Esta clase de prueba valida el comportamiento de algunos de los métodos públicos de BankAccount
.

import org.junit.Test;
import static org.junit.Assert.*;

// Class that tests

https://riptutorial.com/es/home 4
 public class BankAccountTest{

BankAccount acc;

@Before // This will run **before** EACH @Test

public void setUptestDepositUpdatesBalance(){
acc = new BankAccount(100);
}

@After // This Will run **after** EACH @Test

public void tearDown(){
// clean up code
}

@Test
public void testDeposit(){
// no need to instantiate a new BankAccount(), @Before does it for us

acc.deposit(100);

assertEquals(acc.getBalance(),200);
}

@Test
public void testWithdrawUpdatesBalance(){
acc.withdraw(30);

assertEquals(acc.getBalance(),70); // pass
}

@Test
public void testWithdrawAppliesPenaltyWhenOverdrawn(){

acc.withdraw(120);

assertEquals(acc.getBalance(),-30);
}
}

Prueba de unidad con parámetros usando NUnit y C #

using NUnit.Framework;

namespace MyModuleTests
{
[TestFixture]
public class MyClassTests
{
[TestCase(1, "Hello", true)]
[TestCase(2, "bye", false)]
public void MyMethod_WhenCalledWithParameters_ReturnsExpected(int param1, string
param2, bool expected)
{
//Arrange
var foo = new MyClass(param1);

//Act
var result = foo.MyMethod(param2);

https://riptutorial.com/es/home 5
 //Assert
Assert.AreEqual(expected, result);
}
}
}

Una prueba básica de unidad de pitón.

import unittest

def addition(*args):
""" add two or more summands and return the sum """

if len(args) < 2:
raise ValueError, 'at least two summands are needed'

for ii in args:
if not isinstance(ii, (int, long, float, complex )):
raise TypeError

# use build in function to do the job

return sum(args)

Ahora la parte de prueba:

class Test_SystemUnderTest(unittest.TestCase):

def test_addition(self):
"""test addition function"""

# use only one summand - raise an error

with self.assertRaisesRegexp(ValueError, 'at least two summands'):
addition(1)

# use None - raise an error

with self.assertRaises(TypeError):
addition(1, None)

# use ints and floats

self.assertEqual(addition(1, 1.), 2)

# use complex numbers

self.assertEqual(addition(1, 1., 1+2j), 3+2j)

if __name__ == '__main__':
unittest.main()

Una prueba XUnit con parámetros.

using Xunit;

public class SimpleCalculatorTests

{
[Theory]
[InlineData(0, 0, 0, true)]
[InlineData(1, 1, 2, true)]

https://riptutorial.com/es/home 6
 [InlineData(1, 1, 3, false)]
public void Add_PassMultipleParameters_VerifyExpected(
int inputX, int inputY, int expected, bool isExpectedCorrect)
{
// Arrange
var sut = new SimpleCalculator();

// Act
var actual = sut.Add(inputX, inputY);

// Assert
if (isExpectedCorrect)
{
Assert.Equal(expected, actual);
}
else
{
Assert.NotEqual(expected, actual);
}
}
}

public class SimpleCalculator

{
public int Add(int x, int y)
{
return x + y;
}
}

Lea Comenzando con la prueba unitaria en línea: https://riptutorial.com/es/unit-

testing/topic/570/comenzando-con-la-prueba-unitaria

https://riptutorial.com/es/home 7
Capítulo 2: Guía de pruebas unitarias en
Visual Studio para C #
Introducción
Cómo crear un proyecto de prueba de unidad y pruebas de unidad y cómo ejecutar las pruebas
de unidad y la herramienta de cobertura de código.

En esta guía, se utilizará el marco estándar de MSTest y la herramienta estándar de análisis de

cobertura de código que están disponibles en Visual Studio.

La guía fue escrita para Visual Studio 2015, por lo que es posible que algunas cosas sean
diferentes en otras versiones.

Examples
Creando un proyecto de prueba unitaria

• Abra el proyecto C #
• Haga clic derecho en la solución -> Agregar -> Nuevo proyecto ...
• (Figura 1)

• Vaya a Instalado -> Visual C # -> Prueba

• Haga clic en Proyecto de prueba de unidad
• Dale un nombre y haz clic en Aceptar

https://riptutorial.com/es/home 8
 • (Figura 2)

• El proyecto de prueba unitaria se añade a la solución.

• (Figura 3)

Añadiendo la referencia a la aplicación que quieres probar.

• En el proyecto de prueba de unidad, agregue una referencia al proyecto que desea probar
• Haga clic derecho en Referencias -> Agregar referencia ...
• (Figura 3)

https://riptutorial.com/es/home 9
 • Seleccione el proyecto que desea probar
• Ir a Proyectos -> Solución
• Marque la casilla de verificación del proyecto que desea probar -> haga clic en Aceptar
• (Figura 4)

Dos métodos para crear pruebas unitarias.

Método 1
• Ve a tu clase de prueba de unidad en el proyecto de prueba de unidad

https://riptutorial.com/es/home 10
 • Escribe una prueba unitaria

[Testclass]
public class UnitTest1
{
[TestMethod]
public void TestMethod1()
{
//Arrange
ApplicationToTest.Calc ClassCalc = new ApplicationToTest.Calc();
int expectedResult = 5;

//Act
int result = ClassCalc.Sum(2,3);

//Assert
Assert.AreEqual(expectedResult, result);
}
}

Método 2
• Ve al método que quieras probar.
• Haga clic derecho en el método -> Crear pruebas unitarias
• (Figura 4)

• Establecer marco de prueba para MSTest

• Establecer el Proyecto de prueba con el nombre de su proyecto de prueba de unidad
• Establezca el archivo de salida con el nombre de la clase de las pruebas unitarias
• Establezca el código para el método de prueba en una de las opciones enumeradas que
prefiera
• Las otras opciones se pueden editar pero no es necesario.

(Consejo: si aún no ha realizado un proyecto de pruebas de unidad, aún puede usar esta opción.
Simplemente configure Proyecto de prueba en y Archivo de salida en. Creará el proyecto de
prueba de unidad y agregará la referencia del proyecto a la proyecto de prueba de unidad)

• (Figura 5)

https://riptutorial.com/es/home 11
 • Como puede ver a continuación, crea la base de la prueba de unidad para que la complete
• (Figura 6)

Ejecutando pruebas unitarias dentro de Visual Studio

• Para ver sus pruebas unitarias, vaya a Prueba -> Windows -> Explorador de prueba
• (Figura 1)

https://riptutorial.com/es/home 12
 • Esto abrirá un resumen de todas las pruebas en la aplicación.
• (Figura 2)

• En la figura anterior puede ver que el ejemplo tiene una prueba de unidad y aún no se ha
ejecutado

• Puede hacer doble clic en una prueba para ir al código donde se define la prueba de la
unidad

• Puede ejecutar pruebas individuales o múltiples con Ejecutar todo o Ejecutar ...

• También puede ejecutar pruebas y cambiar la configuración desde el menú Prueba (Figura
1)

Ejecutando análisis de cobertura de código dentro de Visual Studio

• Para ver sus pruebas unitarias, vaya a Prueba -> Windows -> Resultados de cobertura de
código
• (Figura 1)

https://riptutorial.com/es/home 13
 • Se abrirá la siguiente ventana.
• (Figura 2)

• La ventana está ahora vacía.

• Vaya al menú Prueba -> Analizar cobertura de código
• (Figura 3)

• Las pruebas ahora también se ejecutarán (vea los resultados en el Explorador de pruebas)
• Los resultados se mostrarán en una tabla con usted puede ver qué clases y métodos están
cubiertos con las pruebas unitarias y cuáles no.
• (Figura 4)

https://riptutorial.com/es/home 14
Lea Guía de pruebas unitarias en Visual Studio para C # en línea: https://riptutorial.com/es/unit-
testing/topic/9953/guia-de-pruebas-unitarias-en-visual-studio-para-c-sharp

https://riptutorial.com/es/home 15
Capítulo 3: Inyección de dependencia
Observaciones
Un enfoque que puede adoptarse para escribir software es crear dependencias a medida que se
necesitan. Esta es una forma bastante intuitiva de escribir un programa y es la forma en que la
mayoría de las personas tienden a aprender, en parte porque es fácil de seguir. Uno de los
problemas con este enfoque es que puede ser difícil de probar. Considere un método que realice
algún procesamiento basado en la fecha actual. El método podría contener algún código como el
siguiente:

if (DateTime.Now.Date > processDate)

{
// Do some processing
}

El código tiene una dependencia directa de la fecha actual. Este método puede ser difícil de
probar porque la fecha actual no se puede manipular fácilmente. Un método para hacer que el
código sea más verificable es eliminar la referencia directa a la fecha actual y, en cambio,
proporcionar (o inyectar) la fecha actual al método que realiza el procesamiento. Esta inyección
de dependencia puede hacer que sea mucho más fácil probar aspectos del código mediante el
uso de pruebas dobles para simplificar el paso de configuración de la prueba de la unidad.

Sistemas IOC

Otro aspecto a considerar es la vida de las dependencias; En el caso de que la clase en sí cree
sus propias dependencias (también conocidas como invariantes), entonces es responsable de
eliminarlas. La inyección de dependencia invierte esto (y es por eso que a menudo nos referimos
a una biblioteca de inyección como un sistema de "Inversión de Control") y significa que en lugar
de que la clase sea responsable de crear, administrar y limpiar sus dependencias, un agente
externo (en este caso, el sistema IoC) lo hace en su lugar.

Esto hace que sea mucho más sencillo tener dependencias que se comparten entre instancias de
la misma clase; por ejemplo, considere un servicio que recupera datos de un punto final HTTP
para que una clase los consuma. Dado que este servicio no tiene estado (es decir, no tiene
ningún estado interno), por lo tanto, solo necesitamos una única instancia de este servicio en toda
nuestra aplicación. Si bien es posible (por ejemplo, usar una clase estática) hacerlo manualmente,
es mucho más simple crear la clase y decirle al sistema IoC que se creará como un Singleton ,
por lo que solo existe una instancia de la clase.

Otro ejemplo sería los contextos de base de datos utilizados en una aplicación web, en los que se
requiere un nuevo contexto por solicitud (o hilo) y no por instancia de un controlador; esto permite
que el contexto sea inyectado en cada capa ejecutada por ese hilo, sin tener que pasarlo
manualmente.

Esto libera a las clases consumidoras de tener que gestionar las dependencias.

https://riptutorial.com/es/home 16
Examples
Inyección Constructor

La inyección de constructor es la forma más segura de inyectar dependencias de las que

depende toda una clase. Tales dependencias a menudo se denominan invariantes , ya que una
instancia de la clase no se puede crear sin proporcionarlas. Al requerir que la dependencia se
inyecte en la construcción, se garantiza que un objeto no se puede crear en un estado
incoherente.

Considere una clase que necesita escribir en un archivo de registro en condiciones de error.
Depende de un ILogger , que puede inyectarse y usarse cuando sea necesario.

public class RecordProcessor

{
readonly private ILogger _logger;

public RecordProcessor(ILogger logger)

{
_logger = logger;
}

public void DoSomeProcessing() {

// ...
_logger.Log("Complete");
}
}

A veces, mientras escribe pruebas, puede notar que el constructor requiere más dependencias de
las que realmente se necesitan para un caso que se está probando. Mientras más pruebas de
este tipo tenga, más probable es que su clase rompa el Principio de Responsabilidad Único
(SRP). Por eso no es una buena práctica definir el comportamiento predeterminado para todas las
simulaciones de dependencias inyectadas en la fase de inicialización de la clase de prueba, ya
que puede enmascarar la posible señal de advertencia.

La prueba de unidad para esto se vería como la siguiente:

[Test]
public void RecordProcessor_DependencyInjectionExample()
{
ILogger logger = new FakeLoggerImpl(); //or create a mock by a mocking Framework

var sut = new RecordProcessor(logger); //initialize with fake impl in testcode

Assert.IsTrue(logger.HasCalledExpectedMethod());
}

Inyección de propiedad

La inyección de propiedad permite que las clases dependientes se actualicen después de que se
haya creado. Esto puede ser útil si desea simplificar la creación de objetos, pero aún así permitir

https://riptutorial.com/es/home 17
que las dependencias sean anuladas por sus pruebas con pruebas dobles.

Considere una clase que necesita escribir en un archivo de registro en una condición de error. La
clase sabe cómo construir un Logger predeterminado, pero permite anularlo mediante la inyección
de propiedades. Sin embargo, vale la pena señalar que al usar la inyección de propiedades de
esta manera, está ILogger esta clase con una implementación exacta de ILogger que es
ConcreteLogger en este ejemplo dado. Una posible solución podría ser una fábrica que devuelva la
implementación necesaria de ILogger.

public class RecordProcessor

{
public RecordProcessor()
{
Logger = new ConcreteLogger();
}

public ILogger Logger { get; set; }

public void DoSomeProcessing()

{
// ...
_logger.Log("Complete");
}
}

En la mayoría de los casos, la inyección de constructor es preferible a la inyección de propiedad

porque brinda mejores garantías sobre el estado del objeto inmediatamente después de su
construcción.

Método de inyección

La inyección de métodos es una forma detallada de inyectar dependencias en el procesamiento.

Considere un método que realice algún procesamiento basado en la fecha actual. Es difícil
cambiar la fecha actual de una prueba, por lo que es mucho más fácil pasar una fecha al método
que desea probar.

public void ProcessRecords(DateTime currentDate)

{
foreach(var record in _records)
{
if (currentDate.Date > record.ProcessDate)
{
// Do some processing
}
}
}

Contenedores / Marcos DI

Si bien extraer las dependencias de su código para poder inyectarlas hace que su código sea
más fácil de probar, empuja el problema hacia la jerarquía y también puede generar objetos que
son difíciles de construir. Se han escrito varios marcos de inyección de dependencia /

https://riptutorial.com/es/home 18
contenedores de inversión de control para ayudar a superar este problema. Éstos permiten
registrar mapeos de tipo. Estos registros se utilizan para resolver dependencias cuando se solicita
al contenedor que construya un objeto.

Considera estas clases:

public interface ILogger {

void Log(string message);
}

public class ConcreteLogger : ILogger

{
public ConcreteLogger()
{
// ...
}
public void Log(string message)
{
// ...
}
}
public class SimpleClass
{
public SimpleClass()
{
// ...
}
}

public class SomeProcessor

{
public SomeProcessor(ILogger logger, SimpleClass simpleClass)
{
// ...
}
}

Para construir SomeProcessor , tanto una instancia de ILogger y SimpleClass son obligatorios. Un
contenedor como Unity ayuda a automatizar este proceso.

Primero se debe construir el contenedor y luego se registran las asignaciones. Esto generalmente
se hace solo una vez dentro de una aplicación. El área del sistema donde ocurre esto se conoce
comúnmente como la Raíz de composición

// Register the container

var container = new UnityContainer();

// Register a type mapping. This allows a `SimpleClass` instance

// to be constructed whenever it is required.
container.RegisterType<SimpleClass, SimpleClass>();

// Register an instance. This will use this instance of `ConcreteLogger`

// Whenever an `ILogger` is required.
container.RegisterInstance<ILogger>(new ConcreteLogger());

Una vez que se configura el contenedor, se puede usar para crear objetos, resolviendo

https://riptutorial.com/es/home 19
automáticamente las dependencias según sea necesario:

var processor = container.Resolve<SomeProcessor>();

Lea Inyección de dependencia en línea: https://riptutorial.com/es/unit-testing/topic/597/inyeccion-

de-dependencia

https://riptutorial.com/es/home 20
Capítulo 4: Las reglas generales para la
prueba unitaria para todos los idiomas.
Introducción
Al comenzar con la prueba unitaria surgen todo tipo de preguntas:

¿Qué es la prueba unitaria? ¿Qué es un SetUp y TearDown? ¿Cómo trato con las dependencias?
¿Por qué hacer pruebas de unidad en absoluto? ¿Cómo hago buenas pruebas unitarias?

Este artículo responderá todas estas preguntas, para que pueda comenzar la prueba de unidad
en el idioma que desee.

Observaciones

¿Qué es la prueba unitaria?

La prueba unitaria es la prueba del código para garantizar que realiza la tarea que debe realizar.
Prueba el código en el nivel más bajo posible: los métodos individuales de sus clases.

¿Qué es una unidad?

Cualquier módulo discreto de código que pueda ser probado de forma aislada. La mayoría de las
clases de tiempo y sus métodos. Esta clase se conoce generalmente como la "Clase bajo prueba"
(CUT) o el "Sistema bajo prueba" (SUT)

La diferencia entre las pruebas unitarias y las pruebas de

integración.
La prueba de unidad es el acto de probar una sola clase en forma aislada, completamente aparte
de cualquiera de sus dependencias en realidad. La prueba de integración es el acto de probar
una sola clase junto con una o más de sus dependencias reales.

El SetUp y TearDown
Cuando se realiza, el método de configuración se ejecuta antes de cada prueba de unidad y el
TearDown después de cada prueba.

En general, agrega todos los pasos de requisitos previos en la Configuración y todos los pasos de
limpieza en el TearDown. Pero solo crea estos métodos si estos pasos son necesarios para cada
prueba. Si no, que estos pasos se toman dentro de las pruebas específicas en la sección
"organizar".

https://riptutorial.com/es/home 21
Como lidiar con las dependencias.
Muchas veces una clase tiene la dependencia de otras clases para ejecutar sus métodos. Para
poder no depender de estas otras clases, tienes que falsificarlas. Puede crear estas clases usted
mismo o usar un marco de aislamiento o de maqueta. Un marco de aislamiento es una colección
de código que permite la creación fácil de clases falsas.

Clases falsas
Cualquier clase que proporcione funcionalidad suficiente para pretender que es una dependencia
que necesita un CUT. Hay dos tipos de falsificaciones: Stubs y Mocks.

• Un código auxiliar: un falso que no tiene ningún efecto en la aprobación o el fracaso de la

prueba y que existe únicamente para permitir que la prueba se ejecute.
• Un simulacro: un falso que realiza un seguimiento del comportamiento de la CUT y pasa o
falla la prueba basada en ese comportamiento.

¿Por qué pruebas de unidad?

1. Las pruebas unitarias encontrarán errores.

Cuando escribe un conjunto completo de pruebas que definen cuál es el

comportamiento esperado para una clase determinada, se revela todo lo que no se
comporta como se espera.

2. La prueba de la unidad mantendrá a los insectos alejados

Realice un cambio que introduzca un error y sus pruebas pueden revelarlo la próxima
vez que ejecute las pruebas.

3. La prueba de la unidad ahorra tiempo

Escribir pruebas unitarias ayuda a garantizar que su código funcione correctamente

desde el principio. Las pruebas unitarias definen lo que su código debe hacer y, por lo
tanto, no pasará tiempo escribiendo un código que haga cosas que no debería hacer.
Nadie comprueba en el código que no cree que funcione y usted tiene que hacer algo
para hacerse creer que funciona. Pasa ese tiempo para escribir pruebas unitarias.

4. La prueba de unidad le da tranquilidad.

Puede ejecutar todas esas pruebas y saber que su código funciona como se supone.
Saber el estado de su código, que funciona y que puede actualizarlo y mejorarlo sin
temor es algo muy bueno.

5. Las pruebas unitarias documentan el uso adecuado de una clase.

Las pruebas unitarias se convierten en ejemplos simples de cómo funciona su código,

https://riptutorial.com/es/home 22
 qué se espera que haga y la forma correcta de usar su código que se está probando.

Reglas generales para la prueba unitaria.

1. Para la estructura de una prueba unitaria, siga la regla AAA

Organizar:

Configurar la cosa para ser probado. Me gustan las variables, los campos y las
propiedades para permitir que la prueba se ejecute así como el resultado esperado.

Actúa: llama al método que estás probando.

Afirmar:

Llame al marco de pruebas para verificar que el resultado de su "acto" sea el

esperado.

2. Prueba una cosa a la vez en aislamiento

Todas las clases deben ser probadas en aislamiento. No deben depender de otra cosa
que no sean las burlas y los talones. No deben depender de los resultados de otras
pruebas.

3. Escribe primero las pruebas simples "justo en el medio"

Las primeras pruebas que escriba deben ser las pruebas más simples. Deben ser los
que, básicamente, ilustran fácilmente la funcionalidad que intenta escribir. Luego, una
vez que esas pruebas pasan, debe comenzar a escribir las pruebas más complicadas
que prueban los bordes y límites de su código.

4. Escribir pruebas que prueben los bordes.

Una vez que se prueban los conceptos básicos y sabes que tu funcionalidad básica
funciona, debes probar los bordes. Un buen conjunto de pruebas explorará los bordes
externos de lo que podría suceder con un método determinado.

Por ejemplo:

• ¿Qué pasa si se produce un desbordamiento?

• ¿Qué pasa si los valores van a cero o por debajo?
• ¿Qué pasa si van a MaxInt o MinInt?
• ¿Qué pasa si creas un arco de 361 grados?
• ¿Qué pasa si pasas una cadena vacía?
• ¿Qué sucede si una cadena tiene un tamaño de 2 GB?

5. Prueba a través de los límites

Las pruebas unitarias deben probar ambos lados de un límite dado. Moverse a través
de los límites son lugares donde su código puede fallar o funcionar de manera

https://riptutorial.com/es/home 23
 impredecible.

6. Si puedes, prueba todo el espectro.

Si es práctico, pruebe todo el conjunto de posibilidades para su funcionalidad. Si se

trata de un tipo enumerado, pruebe la funcionalidad con cada uno de los elementos de
la enumeración. Puede que no sea práctico probar todas las posibilidades, pero si
puede probar todas las posibilidades, hágalo.

7. Si es posible, cubra cada ruta de código

Este también es un desafío, pero si su código está diseñado para pruebas y usted
utiliza una herramienta de cobertura de códigos, puede asegurarse de que cada línea
de su código esté cubierta por pruebas unitarias al menos una vez. La cobertura de
cada ruta de código no garantiza que no haya errores, pero seguramente le brinda
información valiosa sobre el estado de cada línea de código.

8. Escriba pruebas que revelen un error, luego corríjalo

Si encuentras un error, escribe una prueba que lo revele. Luego, puedes corregir
fácilmente el error al depurar la prueba. Luego tienes una buena prueba de regresión
para asegurarte de que si el error regresa por alguna razón, lo sabrás de inmediato.
Es realmente fácil corregir un error cuando tiene una prueba simple y directa para
ejecutar en el depurador.

Un beneficio adicional aquí es que has probado tu prueba. Debido a que ha visto fallar
la prueba y luego, cuando la ha pasado, sabe que la prueba es válida porque se ha
demostrado que funciona correctamente. Esto hace que sea una prueba de regresión
aún mejor.

9. Hacer que cada prueba sea independiente la una de la otra.

Las pruebas nunca deben depender unas de otras. Si sus pruebas tienen que
ejecutarse en un cierto orden, necesita cambiar las pruebas.

10. Escribe un aserto por prueba

Usted debe escribir una aserción por prueba. Si no puede hacer eso, refractor su
código para que sus eventos SetUp y TearDown se usen para crear correctamente el
entorno para que cada prueba se pueda ejecutar de forma individual.

11. Nombra tus pruebas claramente. No tengas miedo de los nombres largos

Ya que estás haciendo una aseveración por prueba, cada prueba puede terminar
siendo muy específica. Por lo tanto, no tenga miedo de usar nombres largos y
completos de pruebas.

Un nombre largo y completo le permite saber de inmediato qué prueba falló y

exactamente qué intentaba hacer la prueba.

https://riptutorial.com/es/home 24
 Las pruebas largas y claramente nombradas también pueden documentar sus
pruebas. Una prueba llamada "DividedByZeroShouldThrowException" documenta
exactamente lo que hace el código cuando intenta dividir por cero.

12. Prueba de que cada excepción planteada es realmente levantada

Si su código genera una excepción, escriba una prueba para asegurarse de que todas
las excepciones que en realidad genere se produzcan cuando se supone que deben
hacerlo.

13. Evita el uso de CheckTrue o Assert.IsTrue

Evite verificar si hay una condición booleana. Por ejemplo, en lugar de verificar si dos
cosas son iguales a CheckTrue o Assert.IsTrue, use CheckEquals o Assert.IsEqual en
su lugar. ¿Por qué? Debido a esto:

CheckTrue (esperado, real) Esto informará algo como: "Algunas pruebas fallaron: se
esperaba que fuera cierto, pero el resultado real fue falso".

Esto no te dice nada.

CheckEquals (Esperado, Actual)

Esto le dirá algo como: "Algunas pruebas fallaron: Se esperaba 7 pero el resultado
real fue 3".

Solo use CheckTrue o Assert.IsTrue cuando su valor esperado sea realmente una
condición booleana.

14. Realiza tus pruebas constantemente.

Ejecute sus pruebas mientras escribe el código. Sus pruebas deben ejecutarse
rápidamente, lo que le permite ejecutarlas incluso después de cambios menores. Si no
puede ejecutar sus pruebas como parte de su proceso de desarrollo normal, entonces
algo va mal. Se supone que las pruebas unitarias se ejecutan casi al instante. Si no lo
están, probablemente es porque no los estás ejecutando de forma aislada.

15. Ejecute sus pruebas como parte de cada compilación automatizada

Del mismo modo que debería realizar la prueba mientras se desarrolla, también deben
ser parte integral de su proceso de integración continua. Una prueba fallida debe
significar que tu construcción está rota. No dejes que las pruebas que fallan
permanezcan. Considéralo un fallo de compilación y repáralo inmediatamente.

Examples
Ejemplo de prueba unitaria simple en C #

Para este ejemplo, probaremos el método de suma de una calculadora simple.

https://riptutorial.com/es/home 25
En este ejemplo probaremos la aplicación: ApplicationToTest. Esta tiene una clase llamada Calc.
Esta clase tiene un método Sum ().

El método Sum () se ve así:

public void Sum(int a, int b)

{
return a + b;
}

La prueba de unidad para probar este método se ve así:

[Testclass]
public class UnitTest1
{
[TestMethod]
public void TestMethod1()
{
//Arrange
ApplicationToTest.Calc ClassCalc = new ApplicationToTest.Calc();
int expectedResult = 5;

//Act
int result = ClassCalc.Sum(2,3);

//Assert
Assert.AreEqual(expectedResult, result);
}
}

Lea Las reglas generales para la prueba unitaria para todos los idiomas. en línea:
https://riptutorial.com/es/unit-testing/topic/9947/las-reglas-generales-para-la-prueba-unitaria-para-
todos-los-idiomas-

https://riptutorial.com/es/home 26
Capítulo 5: Prueba de dobles
Observaciones
Durante las pruebas, a veces es útil usar una prueba doble para manipular o verificar el
comportamiento del sistema bajo prueba. Los dobles se pasan o se inyectan en la clase o método
bajo prueba en lugar de instancias de código de producción.

Examples
Usando un talón para suministrar respuestas enlatadas

Un talón es una prueba de peso ligero doble que proporciona respuestas enlatadas cuando se
llama a los métodos. Cuando una clase bajo prueba se basa en una interfaz o clase base, se
puede implementar una clase alternativa 'stub' para realizar pruebas que se ajusten a la interfaz.

Entonces, asumiendo la siguiente interfaz,

public interface IRecordProvider {

IEnumerable<Record> GetRecords();
}

Si el siguiente método fuera a ser probado

public bool ProcessRecord(IRecordProvider provider)

Se puede escribir una clase de código auxiliar que implementa la interfaz para devolver datos
conocidos al método que se está probando.

public class RecordProviderStub : IRecordProvider

{
public IEnumerable<Record> GetRecords()
{
return new List<Record> {
new Record { Id = 1, Flag=false, Value="First" },
new Record { Id = 2, Flag=true, Value="Second" },
new Record { Id = 3, Flag=false, Value="Third" }
};
}
}

Esta implementación de código auxiliar se puede proporcionar al sistema bajo prueba para influir
en su comportamiento.

var stub = new RecordProviderStub();

var processed = sut.ProcessRecord(stub);

https://riptutorial.com/es/home 27
Usando un marco de burla como un trozo

Los términos Mock y Stub a menudo pueden confundirse. Parte de la razón de esto es que
muchos marcos de simulacros también brindan soporte para crear Stubs sin el paso de
verificación asociado con Mocking.

En lugar de escribir una nueva clase para implementar un código auxiliar como en el ejemplo
"Usar un código auxiliar para proporcionar respuestas enlatadas", se pueden usar marcos
burlones.

Utilizando Moq:

var stub = new Mock<IRecordProvider>();

stub.Setup(provider => provider.GetRecords()).Returns(new List<Record> {
new Record { Id = 1, Flag=false, Value="First" },
new Record { Id = 2, Flag=true, Value="Second" },
new Record { Id = 3, Flag=false, Value="Third" }
});

Esto logra el mismo comportamiento que el código codificado a mano, y se puede suministrar al
sistema bajo prueba de una manera similar:

var processed = sut.ProcessRecord(stub.Object);

Usando un marco de burla para validar el comportamiento

Las simulaciones se utilizan cuando es necesario verificar las interacciones entre el sistema
sometido a prueba y la prueba de dobles. Se debe tener cuidado para evitar crear pruebas
demasiado frágiles, pero la burla puede ser particularmente útil cuando el método para probar es
simplemente organizar otras llamadas.

Esta prueba verifica que cuando se llama al método bajo prueba ( ProcessRecord ), se llama al
método de servicio ( UseValue ) para el Record donde Flag==true . Para ello, configura un apéndice
con datos enlatados:

var stub = new Mock<IRecordProvider>();

stub.Setup(provider => provider.GetRecords()).Returns(new List<Record> {
new Record { Id = 1, Flag=false, Value="First" },
new Record { Id = 2, Flag=true, Value="Second" },
new Record { Id = 3, Flag=false, Value="Third" }
});

Luego configura un simulacro que implementa la interfaz IService :

var mockService = new Mock<IService>();

mockService.Setup(service => service.UseValue(It.IsAny<string>())).Returns(true);

Luego se suministran al sistema bajo prueba y se llama al método a probar.

https://riptutorial.com/es/home 28
 var sut = new SystemUnderTest(mockService.Object);

var processed = sut.ProcessRecord(stub.Object);

El simulacro puede ser interrogado para verificar que se haya realizado la llamada esperada. En
este caso, una llamada a UseValue , con un parámetro "Segundo", que es el valor del registro
donde Flag==true .

mockService.Verify(service => service.UseValue("Second"));

Lea Prueba de dobles en línea: https://riptutorial.com/es/unit-testing/topic/615/prueba-de-dobles

https://riptutorial.com/es/home 29
Capítulo 6: Pruebas unitarias de Loops (Java)
Introducción
Los bucles considerados como una de las estructuras de control importantes en cualquier
lenguaje de programación. Hay diferentes maneras en que podemos lograr la cobertura de bucle.

Estos métodos difieren según el tipo de bucle.

Bucles individuales

Bucles anidados

Bucles concatenados

Examples
Prueba de un solo bucle

Estos son bucles en los que su cuerpo de bucle no contiene otros bucles (el bucle más interno en
el caso de anidados).

Para tener cobertura de bucle, los evaluadores deben realizar las pruebas que se indican a
continuación.

Prueba 1: Diseñe una prueba en la que el cuerpo del bucle no se ejecute en absoluto (es decir,
cero iteraciones)

Prueba 2: Diseñe una prueba en la que la variable de bucle-control sea negativa (número
negativo de iteraciones)

Prueba 3: Diseñe una prueba en la que el bucle se repita una sola vez.

Prueba 4: Diseñe una prueba en la que el bucle se repita dos veces

Prueba 5: Diseñe una prueba en la que el bucle itere cierto número de veces, digamos m donde
m <número máximo de iteraciones posible

Prueba 6: Diseñe una prueba en la que el bucle itere uno menos que el número máximo de
iteraciones

Prueba 7: Diseñe una prueba en la que el bucle recita el número máximo de iteraciones

Prueba 8: Diseñe una prueba en la que el bucle se repita una vez más que el número máximo de
iteraciones

Considere el siguiente ejemplo de código que aplica todas las condiciones especificadas.

https://riptutorial.com/es/home 30
clase pública SimpleLoopTest {

números int [] privados = {5, -77,8, -11,4,1, -20,6,2,10};

/** Compute total of positive numbers in the array

* @param numItems number of items to total.
*/
public int findSum(int numItems)
{
int total = 0;
if (numItems <= 10)
{
for (int count=0; count < numItems; count = count + 1)
{
if (numbers[count] > 0)
{
total = total + numbers[count];
}
}
}
return total;
}

clase pública TestPass extiende TestCase {

public void testname() throws Exception {

SimpleLoopTest s = new SimpleLoopTest();

assertEquals(0, s.findSum(0)); //Test 1
assertEquals(0, s.findSum(-1)); //Test 2
assertEquals(5, s.findSum(1)); //Test 3
assertEquals(5, s.findSum(2)); //Test 4
assertEquals(17, s.findSum(5)); //Test 5
assertEquals(26, s.findSum(9)); //Test 6
assertEquals(36, s.findSum(10)); //Test 7
assertEquals(0, s.findSum(11)); //Test 8
}

Prueba de bucles anidados

Un bucle anidado es un bucle dentro de un bucle.

El bucle externo cambia solo después de que el bucle interno esté completamente terminado /
interrumpido.

En este caso, los casos de prueba deben diseñarse de tal manera que

Comience en el bucle más interno. Establecer todos los bucles externos a sus valores mínimos.
Realice pruebas de bucle simple en el bucle más interno (Test3 / Test4 / Test5 / Test6 / Test7).
Continuar hasta que todos los bucles probados

https://riptutorial.com/es/home 31
Prueba de bucles concatenados

Se concatenan dos bucles si es posible alcanzar uno después de salir del otro en el mismo
camino de entrada a salida. A veces estos dos bucles son independientes entre sí. En esos
casos, podemos aplicar las técnicas de diseño especificadas como parte de las pruebas de bucle
único.

Pero si los valores de iteración en un bucle están relacionados directa o indirectamente con los
valores de iteración de otro bucle y pueden ocurrir en la misma ruta, entonces podemos
considerarlos como bucles anidados.

Lea Pruebas unitarias de Loops (Java) en línea: https://riptutorial.com/es/unit-

testing/topic/10116/pruebas-unitarias-de-loops--java-

https://riptutorial.com/es/home 32
Capítulo 7: Pruebas Unitarias: Mejores
Prácticas
Introducción
Una prueba de unidad es la parte comprobable más pequeña de una aplicación, como funciones,
clases, procedimientos, interfaces. La prueba de unidad es un método mediante el cual se
prueban las unidades individuales del código fuente para determinar si son aptas para el uso. Los
desarrolladores de software básicamente escriben y ejecutan las pruebas unitarias para
asegurarse de que el código cumple con su diseño y sus requisitos y se comporta como se
espera.

Examples
Buen nombramiento

La importancia de un buen nombramiento, puede ilustrarse mejor con algunos malos ejemplos:

[Test]
Test1() {...} //Cryptic name - absolutely no information

[Test]
TestFoo() {...} //Name of the function - and where can I find the expected behaviour?

[Test]
TestTFSid567843() {...} //Huh? You want me to lookup the context in the database?

Las buenas pruebas necesitan buenos nombres. Buena prueba no prueba métodos, los
escenarios de prueba o requisitos.

La buena denominación también proporciona información sobre el contexto y el comportamiento

esperado. Idealmente, cuando la prueba falla en su máquina de compilación, debería poder
decidir qué está mal, sin mirar el código de prueba, o incluso más difícil, tener la necesidad de
depurarlo.

Una buena asignación de nombres le ahorra tiempo para leer el código y depurar:

[Test]
public void GetOption_WithUnkownOption_ReturnsEmptyString() {...}
[Test]
public void GetOption_WithUnknownEmptyOption_ReturnsEmptyString() {...}

Para los principiantes, puede ser útil comenzar el nombre de la prueba con un prefijo
Aseguramiento o similar. Comience con un "Garantía de que_" ayuda a comenzar a pensar en el
escenario o requisito, que necesita una prueba:

https://riptutorial.com/es/home 33
 [Test]
public void EnsureThat_GetOption_WithUnkownOption_ReturnsEmptyString() {...}
[Test]
public void EnsureThat_GetOption_WithUnknownEmptyOption_ReturnsEmptyString() {...}

El nombramiento es importante para los accesorios de prueba también. Nombre el dispositivo de

prueba después de la clase que se está probando:

[TestFixture]
public class OptionsTests //tests for class Options
{
...
}

La conclusión final es:

La buena denominación conduce a buenas pruebas que conducen a un buen diseño en el código
de producción.

De lo simple a lo complejo.

Igual que con las clases de escritura: comience con los casos simples, luego agregue el requisito
(también conocido como pruebas) y la implementación (también conocido como código de
producción) caso por caso:

[Test]
public void EnsureThat_IsLeapYearIfDecimalMultipleOf4() {...}
[Test]
public void EnsureThat_IsNOTLeapYearIfDecimalMultipleOf100 {...}
[Test]
public void EnsureThat_IsLeapYearIfDecimalMultipleOf400 {...}

No olvide el paso de refactorización, cuando haya terminado con los requisitos: primero
refactorice el código, luego refactorice las pruebas

Cuando termine, debe tener una documentación completa, actualizada y LECTURA de su clase.

Concepto de MakeSut

Testcode tiene las mismas exigencias de calidad que el código de producción. MakeSut ()

• mejora la legibilidad
• puede ser fácilmente refaccionado
• perfectamente compatible con la inyección de dependencia.

Aquí está el concepto:

[Test]
public void TestSomething()
{
var sut = MakeSut();

https://riptutorial.com/es/home 34
 string result = sut.Do();
Assert.AreEqual("expected result", result);
}

El MakeSut () más simple simplemente devuelve la clase probada:

private ClassUnderTest MakeSUT()

{
return new ClassUnderTest();
}

Cuando se necesitan dependencias, se pueden inyectar aquí:

private ScriptHandler MakeSut(ICompiler compiler = null, ILogger logger = null, string

scriptName="", string[] args = null)
{
//default dependencies can be created here
logger = logger ?? MockRepository.GenerateStub<ILogger>();
...
}

Se podría decir que MakeSut es solo una alternativa simple para los métodos de configuración y
desmontaje proporcionados por los marcos de prueba de Testrunner y podría considerar estos
métodos como un mejor lugar para realizar una configuración y desmontaje específicos de
prueba.

Todos pueden decidir por su cuenta, qué forma de usar. Para mí, MakeSut () proporciona una
mejor legibilidad y mucha más flexibilidad. Por último, pero no menos importante, el concepto es
independiente de cualquier marco de ejecución de pruebas.

Lea Pruebas Unitarias: Mejores Prácticas en línea: https://riptutorial.com/es/unit-

testing/topic/6074/pruebas-unitarias--mejores-practicas

https://riptutorial.com/es/home 35
Capítulo 8: Tipos de aserción
Examples
Verificando un valor devuelto

[Test]
public void Calculator_Add_ReturnsSumOfTwoNumbers()
{
Calculator calculatorUnderTest = new Calculator();

double result = calculatorUnderTest.Add(2, 3);

Assert.AreEqual(5, result);
}

Pruebas basadas en el estado

Dada esta clase simple, podemos probar que el método ShaveHead funciona correctamente al
afirmar que el estado de la variable HairLength se establece en cero después de ShaveHead método
ShaveHead .

public class Person

{
public string Name;
public int HairLength;

public Person(string name, int hairLength)

{
this.Name = name;
this.HairLength = hairLength;
}

public void ShaveHead()

{
this.HairLength = 0;
}
}

[Test]
public void Person_ShaveHead_SetsHairLengthToZero()
{
Person personUnderTest = new Person("Danny", 10);

personUnderTest.ShaveHead();

int hairLength = personUnderTest.HairLength;

Assert.AreEqual(0, hairLength);
}

Verificando que una excepción es lanzada

https://riptutorial.com/es/home 36
A veces es necesario afirmar cuando se lanza una excepción. Los distintos marcos de prueba de
unidad tienen diferentes convenciones para afirmar que se lanzó una excepción (como el método
Assert.Throws de NUnit). Este ejemplo no utiliza ningún método específico del marco, solo está
integrado en el manejo de excepciones.

[Test]
public void GetItem_NegativeNumber_ThrowsArgumentInvalidException
{
ShoppingCart shoppingCartUnderTest = new ShoppingCart();
shoppingCartUnderTest.Add("apple");
shoppingCartUnderTest.Add("banana");

double invalidItemNumber = -7;

bool exceptionThrown = false;

try
{
shoppingCartUnderTest.GetItem(invalidItemNumber);
}
catch(ArgumentInvalidException e)
{
exceptionThrown = true;
}

Assert.True(exceptionThrown);
}

Lea Tipos de aserción en línea: https://riptutorial.com/es/unit-testing/topic/6330/tipos-de-asercion

https://riptutorial.com/es/home 37
Creditos
S.
Capítulos Contributors
No

Andrey, Carl Manaster, Community, Farukh, forsvarir, Fred

Comenzando con la
1 Kleuver, mahei, mark_h, Quill, silver, Stephen Byrne, Thomas
prueba unitaria
Weller, zhon

Guía de pruebas
2 unitarias en Visual DarkAngel
Studio para C #

Inyección de
3 forsvarir, kayess, mrAtari, Pavel Voronin, Stephen Byrne
dependencia

Las reglas generales

para la prueba
4 DarkAngel
unitaria para todos
los idiomas.

5 Prueba de dobles forsvarir

Pruebas unitarias de
6 Remya
Loops (Java)

Pruebas Unitarias:
7 mrAtari, RamenChef, Shrinivas Patgar, user2314737
Mejores Prácticas

8 Tipos de aserción Danny

https://riptutorial.com/es/home 38