¿Qué es la prueba unitaria?

No estoy en desacuerdo con Dan (aunque una mejor opción puede ser simplemente no responder)...pero...

La prueba unitaria es el proceso de escribir código para probar el comportamiento y la funcionalidad de su sistema.

Obviamente, las pruebas mejoran la calidad de su código, pero eso es solo un beneficio superficial de las pruebas unitarias. Los beneficios reales son:

1. Facilita el cambio de la implementación técnica mientras te aseguras de no cambiar el comportamiento (refactorización). Correctamente la unidad el código probado se puede refactorizar/limpiar agresivamente con pocas posibilidades de romper cualquier cosa sin darse cuenta.
2. Dé confianza a los desarrolladores al agregar comportamientos o hacer correcciones.
3. Documente su código
4. Indica las áreas de tu código que están estrechamente acopladas. Es difícil probar el código de unidad que está estrechamente acoplado
5. Proporcionar un medio para utilizar su API y buscar dificultades desde el principio
6. Indica métodos y clases que no son muy cohesivos

Usted debe unidad de prueba porque es en su interés para entregar un producto mantenible y de calidad a su cliente.

Le sugiero que lo use para cualquier sistema, o parte de un sistema, que modele el comportamiento del mundo real. En otras palabras, es particularmente adecuado para el desarrollo empresarial. No lo usaría para programas desechables / de utilidad. No lo usaría para partes de un sistema que son problemáticas de probar (UI es un ejemplo común, pero no siempre es el caso)

El mayor escollo es que los desarrolladores prueban una unidad demasiado grande, o consideran que un método es una unidad. Esto es particularmente cierto si no comprende Inversión de Control, en cuyo caso sus pruebas unitarias siempre se convertirán en pruebas de integración de extremo a extremo. La prueba unitaria debe evaluar los comportamientos individuales , y la mayoría de los métodos tienen muchos comportamientos.

El mayor error es que los programadores no deberían probar. Solo los programadores malos o perezosos creen eso. ¿Debería el tipo que construye tu techo no probarlo? Deber ¿el médico que reemplaza una válvula cardíaca no analiza la nueva válvula? Solo un programador puede probar que su código hace lo que pretendía que hiciera (QA puede probar casos extremos - cómo se comporta el código cuando se le dice que haga cosas que el programador no pretendía, y el cliente puede hacer una prueba de aceptación - hace el código lo que el cliente pagó por hacer)

La principal diferencia de las pruebas unitarias, a diferencia de "solo abrir un nuevo proyecto y probar este código específico" es que es automatizado, por lo tanto repetible.

Si prueba su código manualmente, puede convencerle de que el código funciona perfectamente - en su estado actual. ¿Pero qué tal una semana después, cuando hiciste una ligera modificación? ¿Estás dispuesto a volver a probarlo a mano cada vez que algo cambie en tu código? Lo más probable es que no :-(

Pero si puedes ejecutar tus pruebas en cualquier momento, con un solo clic, exactamente de la misma manera, dentro de unos segundos, entonces te mostrarán inmediatamente cada vez que algo se rompa. Y si también integra las pruebas unitarias en su proceso de compilación automatizado, le alertarán de errores incluso en los casos en que un cambio aparentemente no relacionado rompió algo en una parte distante de la base de código, cuando ni siquiera se le ocurriría que hay una necesidad de volver a probar eso funcionalidad particular.

Esta es la principal ventaja de las pruebas unitarias sobre las pruebas manuales. Pero espera, hay más:

• las pruebas unitarias acortan drásticamente el bucle de retroalimentación de desarrollo: con un departamento de pruebas separado, puede tomar semanas para que sepa que hay un error en su código, momento en el que ya ha olvidado gran parte del contexto, por lo que puede tomar horas para encontrar y corregir el error; OTOH con las pruebas unitarias, el ciclo de retroalimentación se mide en segundos, y el proceso de corrección de errores es típicamente a lo largo de las líneas de un "oh sh * t, olvidé verificar esa condición aquí": -)
• pruebas unitarias efectivas documento (su comprensión de) el comportamiento de su código
• las pruebas unitarias le obligan a reevaluar sus opciones de diseño, lo que resulta en un diseño más simple y limpio

Los marcos de pruebas unitarias, a su vez, facilitan la escritura y ejecución de las pruebas.

Nunca me enseñaron pruebas unitarias en la universidad, y me llevó un tiempo "obtenerlas". Leí sobre ello, dije "ah, correcto, pruebas automatizadas, eso podría ser genial, supongo", y luego me olvidé de ello.

Me tomó un poco más de tiempo antes de que realmente entendiera el punto: Digamos que estás trabajando en un sistema grande y escribes un módulo pequeño. Compila, lo pones a prueba, funciona muy bien, pasas a la siguiente tarea. Nueve meses después y dos versiones después alguien else hace un cambio en alguna aparentemente parte no relacionada del programa, y rompe el módulo. Peor aún, prueban sus cambios, y su código funciona, pero no prueban tu módulo; diablos, puede que ni siquiera sepan que tu módulo existe.

Y ahora tienes un problema: el código roto está en el maletero y nadie lo sabe. El mejor de los casos es que un probador interno lo encuentra antes de enviarlo, pero arreglar el código al final del juego es costoso. Y si ningún probador interno encuentra se...bueno, eso puede ser muy caro.

La solución son las pruebas unitarias. Detectarán problemas cuando escribas código, lo cual está bien, pero podrías haberlo hecho a mano. La verdadera recompensa es que detectarán problemas nueve meses después cuando ahora estés trabajando en un proyecto completamente diferente, pero un pasante de verano cree que se verá más ordenado si esos parámetros están en orden alfabético, y luego la prueba unitaria que escribiste falla, y alguien le arroja cosas al pasante hasta que cambie el orden de los parámetros. Ese es el "por qué" de las pruebas unitarias. :-)

Echando un vistazo a los pros filosóficos de las pruebas unitarias y el TDD aquí hay algunas de las observaciones clave de "bombillas" que me impactaron en mis primeros pasos tentativos en el camino hacia la iluminación del TDD (ninguna original o necesariamente noticia)...

1. TDD NO significa escribir el doble de la cantidad de código. El código de prueba suele ser bastante rápido e indoloro para escribir y es una parte clave de su proceso de diseño y crítico.

2. TDD le ayuda a darse cuenta de cuándo dejar de codificación! Su las pruebas te dan la confianza de que has hecho lo suficiente por ahora y puedes dejar de retocar y pasar a la siguiente cosa.

3. Las pruebas y el código trabajan juntos para lograr un mejor código. Su código podría ser malo / con errores. Su PRUEBA podría ser mala / con errores. En TDD estás apostando a que las posibilidades de que AMBOS sean malos / con errores sean bastante bajas. A menudo es la prueba que necesita ser arreglada, pero sigue siendo un buen resultado.

4. El TDD ayuda a codificar el estreñimiento. Sabes que sentir que ¿tienes tanto que hacer que apenas sabes por dónde empezar? Es viernes por la tarde, si lo postergas un par de horas más... TDD le permite desarrollar muy rápidamente lo que cree que necesita hacer, y hace que su codificación se mueva rápidamente. También, al igual que las ratas de laboratorio, creo que todos respondemos a esa gran luz verde y trabajamos más duro para verla de nuevo!

5. De manera similar, estos diseñadores pueden VER en qué están trabajando. Pueden vagar por un descanso de jugo / cigarrillo / iphone y regrese a un monitor que inmediatamente les da una señal visual de dónde llegaron. TDD nos da algo similar. Es más fácil ver a dónde llegamos cuando la vida interviene...

6. Creo que fue Fowler quien dijo: "Las pruebas imperfectas, que se ejecutan con frecuencia, son mucho mejores que las pruebas perfectas que nunca se escriben". Interpreto esto como darme permiso para escribir pruebas donde creo que serán más útiles incluso si el resto de mi cobertura de código es lamentable incompleto.

7. TDD ayuda en todo tipo de formas sorprendentes en el futuro. Las buenas pruebas unitarias pueden ayudar a documentar lo que se supone que debe hacer algo, pueden ayudarlo a migrar código de un proyecto a otro y brindarle una sensación injustificada de superioridad sobre sus colegas que no realizan pruebas:)

Esta presentación es una excelente introducción a todo lo que implica la prueba de bondad deliciosa.

Me gustaría recomendar el libro xUnit Testing Patterns de Gerard Meszaros. Es grande, pero es un gran recurso en las pruebas unitarias. Aquí hay un enlace a su sitio web donde discute los conceptos básicos de las pruebas unitarias. http://xunitpatterns.com/XUnitBasics.html

Esta es mi opinión. Yo diría que las pruebas unitarias son la práctica de escribir pruebas de software para verificar que su software real hace lo que está destinado a. Esto comenzó con JUnit en el mundo Java y se ha convertido en una buena práctica en PHP, así como con SimpleTest y PHPUnit . Es una práctica básica de la Programación Extrema y le ayuda a estar seguro de que su software todavía funciona según lo previsto después de la edición. Si tiene suficiente cobertura de prueba, puede hacer una refactorización importante, corrección de errores o añadir características rápidamente con mucho menos miedo de introducir otros problemas.

Es más efectivo cuando todas las pruebas unitarias se pueden ejecutar automáticamente.

Las pruebas unitarias generalmente se asocian con el desarrollo de OO. La idea básica es crear un script que configure el entorno para su código y luego lo ejerza; escriba aserciones, especifique la salida prevista que debe recibir y luego ejecute su script de prueba utilizando un marco como los mencionados arriba.

El framework ejecutará todas las pruebas contra su código y luego informará de éxito o fracaso de cada prueba. PHPUnit se ejecuta desde la línea de comandos de Linux por defecto, aunque hay interfaces HTTP disponibles para ello. SimpleTest está basado en la web por naturaleza y es mucho más fácil de poner en marcha, IMO. En combinación con xDebug, PHPUnit puede darle estadísticas automatizadas para la cobertura de código que algunas personas encuentran muy útil.

Algunos equipos escriben hooks desde su subversion repositorio para que las pruebas unitarias se ejecuten automáticamente cada vez que confirme cambios.

Es una buena práctica mantener sus pruebas unitarias en el mismo repositorio que su aplicación.

Uso pruebas unitarias para ahorrar tiempo.

Al construir lógica de negocios (o acceso a datos), la funcionalidad de prueba a menudo puede involucrar escribir cosas en muchas pantallas que pueden o no estar terminadas todavía. La automatización de estas pruebas ahorra tiempo.

Para mí, las pruebas unitarias son una especie de arnés de prueba modularizado. Por lo general, hay al menos una prueba por función pública. Escribo pruebas adicionales para cubrir varios comportamientos.

Todos los casos especiales que pensó al desarrollar el código se puede registrar en el código en las pruebas unitarias. Las pruebas unitarias también se convierten en una fuente de ejemplos sobre cómo usar el código.

Es mucho más rápido para mí descubrir que mi nuevo código rompe algo en mis pruebas unitarias y luego verificar el código y hacer que algún desarrollador de front-end encuentre un problema.

Para las pruebas de acceso a datos trato de escribir pruebas que no tienen ningún cambio o limpiar después de sí mismos.

Las pruebas unitarias no van a ser capaces de resolver todas las pruebas requisito. Podrán ahorrar tiempo de desarrollo y probar las partes principales de la aplicación.

Bibliotecas como NUnit, xUnit o JUnit son solo obligatorios si desea desarrollar sus proyectos utilizando el enfoque TDD popularizado por Kent Beck:

Puedes leer Introducción al Desarrollo Impulsado por Pruebas (TDD) o el libro de Kent Beck Desarrollo Impulsado Por Pruebas: Por Ejemplo.

Entonces, si desea asegurarse de que sus pruebas cubren una parte "buena" de su código, puede usar software como NCover, JCover, PartCover o lo que sea. Te dirán el porcentaje de cobertura de tu código. Dependiendo de cuánto seas experto en TDD, sabrás si lo has practicado lo suficientemente bien:)

La prueba unitaria consiste en escribir código que prueba el código de su aplicación.

La Unidad parte del nombre es sobre la intención de probar pequeñas unidades de código (un método por ejemplo) a la vez.

XUnit está ahí para ayudar con esta prueba - son frameworks que ayudan con esto. Parte de eso son corredores de prueba automatizados que le dicen qué prueba falla y cuáles pasan.

También tienen facilidades para configurar el código común que necesita en cada prueba antes de la mano y derríbalo cuando hayan terminado todas las pruebas.

Puede tener una prueba para verificar que se ha lanzado una excepción esperada, sin tener que escribir todo el bloque try catch usted mismo.

Creo que el punto que no entiendes es que los frameworks de pruebas unitarias como NUnit (y similares) te ayudarán a automatizar pruebas de tamaño pequeño a mediano. Por lo general, puede ejecutar las pruebas en una interfaz gráfica de usuario (ese es el caso con NUnit, por ejemplo) simplemente haciendo clic en un botón y luego - con suerte - ver la barra de progreso permanecer verde. Si se vuelve rojo, el marco le muestra qué prueba falló y qué salió mal exactamente. En una prueba unitaria normal, a menudo se utilizan aserciones, p. ej. Assert.AreEqual(expectedValue, actualValue, "some description") - así que si los dos valores son desiguales verá un error diciendo "alguna descripción: esperado pero fue ".

Como conclusión, las pruebas unitarias harán que las pruebas sean más rápidas y mucho más cómodas para los desarrolladores. Puede ejecutar todas las pruebas unitarias antes de confirmar código nuevo para que no rompa el proceso de compilación de otros desarrolladores en el mismo proyecto.

Use Testivus. Todo lo que necesitas saber está ahí :)

La prueba unitaria es una práctica para asegurarse de que la función o módulo que va a implementar se va a comportar como se espera (requisitos) y también para asegurarse de cómo se comporta en escenarios como condiciones de límite y entrada no válida.

XUnit, NUnit, mbUnit, etc. son herramientas que le ayudan a escribir las pruebas.

El ensayo unitario es el ensayo de una unidad de código (por ejemplo, una función única) sin necesidad de la infraestructura en la que se basa dicha unidad de código. es decir, pruébelo aisladamente.

Si, por ejemplo, la función que está probando se conecta a una base de datos y realiza una actualización, en una prueba unitaria es posible que no desee realizar esa actualización. Lo haría si fuera una prueba de integración, pero en este caso no lo es.

Así que una prueba unitaria ejercitaría la funcionalidad incluida en la" función" pruebas sin efectos secundarios de la actualización de la base de datos.

Digamos que su función recuperó algunos números de una base de datos y luego realizó un cálculo de desviación estándar. ¿Qué intentas probar aquí? Que la desviación estándar se calcula correctamente o que los datos se devuelven de la base de datos?

En una prueba unitaria solo desea probar que la desviación estándar se calcula correctamente. En una prueba de integración que desea probar el cálculo de la desviación estándar y el recuperación de base de datos.

Test Driven Development ha tomado el término Unit Test. Como un anciano mencionaré la definición más genérica de la misma.

Prueba unitaria también significa probar un solo componente en un sistema más grande. Este único componente podría ser una dll, exe, biblioteca de clases, etc. Incluso podría ser un solo sistema en una aplicación multi-sistema. Así que en última instancia, la Prueba Unitaria termina siendo la prueba de lo que quieras llamar una sola pieza de un sistema más grande.

Entonces se movería hacia arriba para pruebas integradas o de sistemas probando cómo funcionan todos los componentes juntos.

En primer lugar, ya sea hablando de pruebas unitarias o cualquier otro tipo de pruebas automatizadas (Integración, Carga, pruebas de interfaz de usuario, etc.), la diferencia clave de lo que sugiere es que es automatizado, repetible y no requiere ningún recurso humano para ser consumido (=nadie tiene que realizar las pruebas, generalmente se ejecutan con solo presionar un botón).

Fui a una presentación sobre pruebas unitarias en FoxForward 2007 y me dijeron que nunca probara unitariamente nada que funcione con datos. Después de todo, si pruebas en datos en vivo, los resultados son impredecibles, y si no pruebas en datos en vivo, en realidad no estás probando el código que escribiste. Desafortunadamente, esa es la mayor parte de la codificación que hago en estos días. :-)

Tomé una oportunidad en TDD recientemente cuando estaba escribiendo una rutina para guardar y restaurar la configuración. Primero, verifiqué que podía crear el almacenamiento objeto. Entonces, que tenía el método que necesitaba llamar. Entonces, eso podría llamarlo. Entonces, que podría pasar los parámetros. Entonces, que podría pasar parámetros específicos. Y así sucesivamente, hasta que finalmente estaba verificando que guardaría la configuración especificada, me permiten cambiarlo y luego restaurarlo, para varias sintaxis diferentes.

No llegué al final, porque necesitaba-la-rutina-ahora-maldita-sea, pero fue un buen ejercicio.

¿Qué haces si te dan un montón de basura y parece que estás atrapado en un estado perpetuo de limpieza que sabes que con la adición de cualquier nueva característica o código puede romper el conjunto actual porque el software actual es como un castillo de naipes?

¿Cómo podemos hacer pruebas unitarias entonces?

Empiezas poco a poco. El proyecto en el que acabo de entrar no tenía pruebas unitarias hasta hace unos meses. Cuando la cobertura era tan baja, simplemente elegíamos un archivo que no tenía cobertura y haga clic en "agregar pruebas".

En este momento estamos por encima del 40%, y nos las hemos arreglado para recoger la mayor parte de la fruta que cuelga bajo.

(La mejor parte es que incluso a este bajo nivel de cobertura, ya nos hemos encontrado con muchas instancias del código haciendo lo incorrecto, y las pruebas lo atraparon. Eso es un gran motivador para empujar a las personas a agregar más pruebas.)

Esto responde por qué debería hacer pruebas unitarias.

Los 3 videos a continuación cubren las pruebas unitarias en javascript, pero los principios generales se aplican en la mayoría de los idiomas.

Pruebas Unitarias: Los Minutos Ahora Ahorrarán Horas Más Tarde-Eric Mann - https://www.youtube.com/watch?v=_UmmaPe8Bzc

JS Unit Testing (muy bueno) - https://www.youtube.com/watch?v=-IYqgx8JxlU

Escribiendo JavaScript comprobable - https://www.youtube.com/watch?v=OzjogCFO4Zo

Ahora estoy aprendiendo sobre el tema, así que puede que no sea 100% correcto y hay más de lo que estoy describiendo aquí, pero mi comprensión básica de las pruebas unitarias es que escribes algún código de prueba (que se mantiene separado de tu código principal) que llama a una función en tu código principal con entrada (argumentos) que la función requiere y el código luego comprueba si obtiene un valor de retorno válido. Si lo hace volver un válido valor el marco de pruebas unitarias que está utilizando para ejecutar las pruebas muestra una luz verde (todo bien) si el valor no es válido, obtiene una luz roja y luego puede solucionar el problema de inmediato antes de lanzar el nuevo código a producción, sin pruebas, es posible que en realidad no haya detectado el error.

Así que escribe pruebas para su código actual y crea el código para que pase la prueba. Meses más tarde, usted o alguien más necesita modificar la función en su código principal, porque antes ya había escrito código de prueba para esa función que ahora se ejecuta de nuevo y la prueba puede fallar porque el codificador introdujo un error lógico en la función o devolver algo completamente diferente de lo que esa función se supone que debe devolver. Una vez más sin la prueba en su lugar que el error podría ser difícil de rastrear, ya que posiblemente puede afectar a otro código, así y pasará desapercibido.

También el hecho de que tenga un programa de computadora que se ejecuta a través de su código y lo prueba en lugar de usted hacerlo manualmente en el navegador página por página ahorra tiempo (pruebas unitarias para javascript). Digamos que modifica una función que es utilizada por algún script en una página web y funciona bien para su nuevo propósito previsto. Pero, digamos también por argumentos que hay otra función que tiene en algún otro lugar en su código que depende de esa función recién modificada para que funcione correctamente. Esta función dependiente ahora puede dejar de funcionar debido a los cambios que ha realizado la primera función, sin embargo, sin pruebas en su lugar que se ejecutan automáticamente por su computadora no se dará cuenta de que hay un problema con esa función hasta que realmente se ejecuta y tendrá que navegar manualmente a una página web que incluye el script que ejecuta la función dependiente, solo entonces se dará cuenta de que hay un error debido al cambio que hizo a la primera función.

Para reiterar, tener pruebas que se ejecutan mientras se desarrolla su aplicación atrapará este tipo de problemas como usted está codificando. Al no tener las pruebas en su lugar, tendría que pasar manualmente por toda su aplicación e incluso entonces puede ser difícil detectar el error, ingenuamente lo envía a producción y después de un tiempo un amable usuario le envía un informe de error (que no será tan bueno como sus mensajes de error en un marco de prueba).

Es bastante confuso cuando escuchas por primera vez sobre el tema y piensas para ti mismo, ¿no estoy ya probando mi código? Y el código que tienes escrito está funcionando como se supone que ya, "¿por qué necesito otro marco?"... Sí, ya está probando su código, pero una computadora es mejor para hacerlo. Solo tiene que escribir pruebas lo suficientemente buenas para una función/unidad de código una vez y el resto se encarga de usted por la poderosa cpu en lugar de tener que comprobar manualmente que todo el código sigue funcionando cuando se hace un cambio en su código.

Además, no tiene que probar unitariamente su código si no lo desea, pero vale la pena a medida que su proyecto/base de código comienza a crecer más a medida que aumentan las posibilidades de introducir errores.

Las pruebas unitarias y TDD en general le permiten tener ciclos de retroalimentación más cortos sobre el software que está escribiendo. En lugar de tener una fase de prueba grande al final de la implementación, usted prueba gradualmente todo lo que escribe. Esto aumenta mucho la calidad del código, como se ve inmediatamente, donde puede tener errores.