¿Un ejemplo de prueba unitaria en C#?

Question

¿Qué es exactamente una prueba de unidad y cómo escribo una? He oído muchas veces que las personas las escriben antes de que se escriba su aplicación, ¿cómo puede ser esto? Tengo la impresión de que una prueba unitaria es un código que hace una llamada a un método de su aplicación con un valor establecido y espera que vuelva un valor específico. Si el valor específico no vuelve, la prueba ha fallado. ¿Me equivoco o engaño aquí? He leído mucho sobre pruebas unitarias pero sé muy poco acerca de cómo se ve realmente en el código, por lo que una muestra sería genial.

¿Es esta una prueba de unidad?

inicio pseudo código ...

CheckForDuplicateSubdomains(){ 
    get all users in DB with matching subdomains 
    if greater than zero, fail test 
} 

PS: Estoy utilizando ASP.NET MVC en C#

Answer 1

Tengo la impresión de que una prueba de unidad es un código que hace una llamada a un método de su aplicación con un valor establecido y espera que un valor específico regrese, si el valor específico no vuelve, la prueba ha fallado. ¿Me equivoco o engaño aquí?

No, tienes razón.

Lo importante con las pruebas unitarias es probar una pequeña porción de código como sea posible.

En su ejemplo, obtiene algo de la base de datos y luego cuenta el número de elementos ... Si su método falla, nunca sabrá exactamente dónde salieron las cosas mal, porque hay tantas cosas que podrían salir mal. ..

su base de datos de la conexión podría perderse, SQL no válida, ...

Si está utilizando asp.net MVC, usted debe tener un tiempo más fácil escribir las pruebas unitarias que si estuviera utilizando asp normal. neto

Answer 2

Una prueba de unidad es una prueba que ejerce una porción muy pequeña de su código, generalmente un único método (una unidad para ser exactos).

En TDD, los desarrolladores pueden escribir la Prueba unitaria antes de codificar el método porque ya saben lo que la Unidad de código debería hacer. No importa cómo hace el trabajo ... la prueba simplemente se asegura de que los resultados sean correctos.

Y ese pseudocódigo podría usarse como una prueba de unidad (no estoy seguro de lo que probaría, pero tendría que asumir que está probando un método que no debe devolver dominios duplicados).

La teoría es que las pruebas unitarias (y el desarrollo controlado por pruebas) deberían aliviar los dolores de cabeza en el futuro asegurándose de que cada Unidad de código haga exactamente lo que se espera de ella.

Answer 3

Tiene razón acerca de las pruebas unitarias. La idea es probar todas sus funciones, una por una, con diferentes entradas para asegurarse de que funcionen como espera (en lugar de descubrirlas una vez que se han insertado en una aplicación ... y luego hacer las pruebas más complicadas).

Escribir las pruebas de unidad antes de escribir la función es parte de una metodología llamada "Desarrollo controlado por prueba". En el que escribe el esqueleto de la función solamente, y todas las pruebas de la unidad primero. Por lo tanto, al principio todas sus pruebas fallarán (b/c la función aún no está programada). Después de eso, programa la función hasta que pasen todas las pruebas.

Answer 4

Sí, su ejemplo sería una prueba de unidad. Hay algunas razones para crear la prueba primero.Primero, actúa como documentación viviente para su proyecto. Establece los comportamientos y los resultados esperados, lo que debería ayudarlo a implementar su código (es más fácil escribir algo, saber qué debe hacer y básicamente cómo se inicia). En segundo lugar, si luego escribes la prueba, es más probable que escribas una prueba que funcione con el código que ya escribiste, lo que no te ayuda. Defina qué necesita hacer una unidad de código, escriba las pruebas y escriba/corrija el código para que refleje los comportamientos en las pruebas. Esta estrategia se traduce en una mejor comprensión y calidad a medida que su aplicación evoluciona.

Answer 5

Las pruebas unitarias son pruebas automatizadas a nivel de Unidad. Por nivel de unidad se refieren a la unidad de código atómico de modo que no se puede desglosar más. una función o una parte particular de un objeto. una prueba de unidad para una función cuadrada sería algo como

assertEqual(4, square(2)); 
assertEqual(4, square(-2)); 
assertEqual(0, square(0)); 

Ahora se puede escribir esto tan pronto como se haya decidido en la interfaz de la plaza, para una función más complicada que podría medir qué tan cerca de completar la función es por cuántas pruebas pasan

Answer 6

Existen convenciones muy bien establecidas para pruebas unitarias en la familia de marcos xUnit, originalmente derivadas de jUnit. En ese marco, la afirmación es el principal vehículo para realizar una prueba. En un conjunto de pruebas, el objetivo es garantizar que el 100% de sus afirmaciones sean verdaderas.

Considere su ejemplo.

CheckForDuplicateSubdomains(){ 
    get all users in DB with matching subdomains 
    if greater than zero, fail test 
} 

Esta prueba convencional tendría un nombre que empieza por "test", que permite corredor de prueba del marco saber que esta función es una prueba y no un método de configuración, por ejemplo. Es importante aclarar que estamos probando el comportamiento del código, y no el estado de los datos.

testNoDuplicateSubdomains(){ 
} 

Dentro de cada prueba, hay four phases:

• configuración accesorio,
• ejercicio SUT, verificación resultado
• y
• desmontaje del accesorio.

El SUT es el "sistema bajo prueba", que normalmente es un método de una clase en su código de producción.

testNoDuplicateSubdomains(){ 
    // fixture setup 
    prepareDatabaseTestData() 
    // exercise SUT, 
    SUT = new ProductionObject() 
    result = SUT.getAllUsersWithMatchingSubDomains() 
    // result verification and 
    assertEmpty(result) // or whatever makes sense 
    // fixture teardown. 
    removeDatabaseTestData() 
} 

Al igual que con muchas técnicas de desarrollo de software, lleva tiempo obtener experiencia en pruebas de unidad de escritura. Un buen recurso para aprender las mejores prácticas es xUnit Test Patterns por Gerard Meszaros.