Aquí podría ser tu PUBLICIDAD


¿Qué es la prueba unitaria?

votos
193

Vi muchas preguntas preguntando 'cómo' a la prueba unitaria en un idioma específico, pero sin preguntar 'qué', 'por qué' y 'cuándo'.

  • ¿Qué es?
  • ¿Qué es lo que hace por mí?
  • ¿Por qué debería usarlo?
  • ¿Cuándo debería usarlo (también cuando no)?
  • Cuáles son algunos escollos y conceptos erróneos comunes
Publicado el 04/08/2008 a las 17:27
fuente por usuario Uberfuzzy
En otros idiomas...        العربية       

20 respuestas

votos
182

Las pruebas unitarias son, en términos generales, pruebas de bits de su código de forma aislada con código de prueba. Las ventajas inmediatas que vienen a la mente son:

  • La ejecución de las pruebas se vuelve automatizable y repetible
  • Puede probar a un nivel mucho más detallado que las pruebas de apuntar y hacer clic a través de una GUI

Tenga en cuenta que si su código de prueba escribe en un archivo, abre una conexión a la base de datos o hace algo en la red, se clasificará más apropiadamente como una prueba de integración. Las pruebas de integración son buenas, pero no deben confundirse con pruebas unitarias. El código de prueba unitaria debe ser corto, dulce y rápido de ejecutar.

Otra forma de ver las pruebas unitarias es que primero se escriben las pruebas. Esto se conoce como desarrollo controlado por pruebas (TDD para abreviar). TDD trae ventajas adicionales:

  • No escribes el código especulativo "Quizás necesite esto en el futuro", solo lo suficiente para que las pruebas pasen
  • El código que has escrito siempre está cubierto por pruebas
  • Al escribir la prueba primero, se ve obligado a pensar cómo desea llamar al código, lo que generalmente mejora el diseño del código a largo plazo.

Si no estás haciendo pruebas unitarias ahora, te recomiendo que comiences con eso. Obtenga un buen libro, prácticamente cualquier xUnit-book lo hará porque los conceptos son muy transferibles entre ellos.

A veces, las pruebas de unidad de escritura pueden ser dolorosas. Cuando se ponga de esa manera, intente encontrar a alguien que lo ayude, y resista la tentación de "simplemente escribir el maldito código". Las pruebas unitarias son muy parecidas a lavar los platos. No siempre es agradable, pero mantiene tu cocina metafórica limpia, y realmente quieres que esté limpia. :)


Edit: me viene a la mente un error, aunque no estoy seguro de si es tan común. Escuché a un gerente de proyecto decir que las pruebas unitarias hicieron que el equipo escribiera todo el código dos veces. Si se ve y se siente de esa manera, bueno, lo estás haciendo mal. La escritura de las pruebas no solo acelera el desarrollo, sino que también le proporciona un indicador conveniente de "ahora he terminado" que de otro modo no tendría.

Respondida el 04/08/2008 a las 05:36
fuente por usuario Rytmis


Aquí podría ser tu PUBLICIDAD


votos
65

No estoy en desacuerdo con Dan (aunque una mejor opción puede ser 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 verdaderos beneficios son:

  1. Facilite el cambio de la implementación técnica y asegúrese de no cambiar el comportamiento (refactorización). El código de la unidad correctamente probado se puede refactorizar / limpiar de forma agresiva con pocas posibilidades de romper algo sin darse cuenta.
  2. Brinde confianza a los desarrolladores cuando agregue comportamiento o realice correcciones.
  3. Documenta tu código
  4. Indique las áreas de su código que están estrechamente conectadas. Es difícil probar el código de unidad que está estrechamente acoplado
  5. Proporcione un medio para usar su API y busque dificultades desde el principio
  6. Indica métodos y clases que no son muy cohesivas

Debe realizar pruebas unitarias porque le conviene entregar un producto de calidad y mantenible a su cliente.

Sugiero que lo uses 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 / utilitarios. No lo usaría para partes de un sistema que son difíciles de probar (la IU es un ejemplo común, pero ese no es siempre el caso)

El mayor inconveniente 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 la Inversión de Control , en cuyo caso las pruebas de su unidad siempre se convertirán en pruebas de integración de extremo a extremo. La prueba unitaria debe evaluar las conductas individuales, y la mayoría de los métodos tienen muchos comportamientos.

El mayor error es que los programadores no deben probar. Solo los programadores malos o flojos creen eso. ¿El tipo que construye su techo no lo prueba? ¿Debería el médico reemplazar una válvula cardíaca no probar la nueva válvula? Solo un programador puede probar que su código hace lo que pretendía (el control de calidad puede probar casos extremos: cómo se comporta el código cuando se le dice que haga cosas que el programador no intentó y el cliente puede hacer pruebas de aceptación; qué es lo que el cliente pagó por hacer)

Respondida el 04/08/2008 a las 05:41
fuente por usuario Karl Seguin

votos
40

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

Si el resultado es el código de forma manual, puede convencer de que el código está funcionando perfectamente - en su estado actual . Pero lo que una semana más tarde, cuando hizo una ligera modificación en ella? ¿Está dispuesto a volver a probar de nuevo con la mano cada vez que algo cambia en su código? Lo más probable es que no :-(

Pero si se puede ejecutar las pruebas en cualquier momento, con un solo clic, exactamente del mismo modo, a los pocos segundos , entonces se mostrará inmediatamente cuando algo se rompe. Y si también integrar las pruebas de unidad en su proceso de construcción automatizado, que le alertarán a los insectos, incluso en los casos en que un cambio aparentemente sin ninguna relación se rompió algo en una parte distante de la base de código - cuando ni siquiera se le ocurrió que existe una necesidad para volver a probar esa funcionalidad en particular.

Esta es la principal ventaja de las pruebas de unidad más de las pruebas de la mano. Pero espera, hay más:

  • pruebas unitarias acortan el ciclo de retroalimentación de desarrollo de manera espectacular: con un departamento de pruebas independiente que puede tomar semanas para que sepan que hay un error en su código, momento en el cual ya se ha olvidado mucho del contexto, por lo que puede tardar horas en encontrar y corregir el error; Otoh con las pruebas de unidad, 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 mierda, se me olvidó para comprobar que la condición aquí" :-)
  • pruebas unitarias efectivamente documentan (su comprensión de) el comportamiento de su código
  • fuerzas de pruebas unitarias volver a evaluar sus opciones de diseño, lo que resulta en un diseño más simple, más limpio

frameworks de pruebas unitarias, a su vez, hacen que sea fácil para que usted pueda escribir y ejecutar las pruebas.

Respondida el 14/03/2010 a las 06:20
fuente por usuario Péter Török

votos
29

Nunca me enseñaron las pruebas unitarias en la universidad, y me tomó un tiempo "obtenerlo". Lo leí, dije "ah, claro, pruebas automáticas, eso podría ser genial, supongo", y luego me olvidé de ello.

Pasó 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 pequeño módulo. Se compila, lo pones a prueba, funciona muy bien, pasas a la siguiente tarea. Nueve meses después y dos versiones más tarde alguien más realiza un cambio en una parte del programa aparentemente no relacionada, y rompe el módulo. Peor aún, prueban sus cambios y su código funciona, pero no prueban su módulo; Diablos, es posible que ni siquiera sepan que su módulo existe .

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

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

Respondida el 19/09/2008 a las 01:45
fuente por usuario Cody Hatch

votos
12

Introduciendo las ventajas filosóficas de las pruebas unitarias y el TDD, aquí están algunas de sus observaciones clave de "bombilla" que me sorprendieron en mis tentativos primeros pasos en el camino hacia la iluminación TDD (ninguna original o necesariamente noticias) ...

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

  2. ¡TDD te ayuda a darte cuenta cuándo detener la codificación! Sus pruebas le dan la confianza de que ya ha hecho lo suficiente por ahora y puede dejar de retocar y pasar a lo siguiente.

  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 estar mal / con errores. En TDD confía en que las posibilidades de que ambos sean malos / con errores son bastante bajos. A menudo es la prueba que debe solucionarse, pero sigue siendo un buen resultado.

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

  5. En una línea similar, estos tipos de diseñadores pueden VER en qué están trabajando. Pueden pasear por un descanso de jugo / cigarrillo / iphone y regresar a un monitor que de inmediato les da una indicación 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, ejecutarse con frecuencia, son mucho mejores que las pruebas perfectas que nunca se escriben en absoluto". Interpreto esto como si me diera permiso para escribir pruebas donde creo que serán más útiles, incluso si el resto de la cobertura de mi código es tristemente 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 el código de un proyecto a otro y le dan una sensación de superioridad injustificada con respecto a sus colegas sin pruebas :)

Esta presentación es una excelente introducción a todas las deliciosas pruebas de bondad que implica.

Respondida el 24/08/2008 a las 10:58
fuente por usuario reefnet_alex

votos
7

Me gustaría recomendar el libro de Patrones Prueba xUnit por Gerard Meszaros. Es grande, pero es un gran recurso en la unidad de pruebas. Aquí hay un enlace a su sitio web en el que se analizan los fundamentos de las pruebas unitarias. http://xunitpatterns.com/XUnitBasics.html

Respondida el 14/03/2010 a las 07:10
fuente por usuario Paul Hildebrandt

votos
5

Yo uso pruebas unitarias para ahorrar tiempo.

Cuando se crea una lógica de negocios (o acceso a datos), la funcionalidad de prueba a menudo implica escribir cosas en muchas pantallas que aún pueden estar terminadas o no. La automatización de estas pruebas ahorra tiempo.

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

Todos los casos especiales que pensaste al desarrollar el código se pueden 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 las pruebas de mi unidad y luego verificar el código y hacer que un desarrollador de aplicaciones para el usuario encuentre un problema.

Para las pruebas de acceso a datos, intento escribir pruebas que no tienen cambios o que no se depuran.

Las pruebas unitarias no serán capaces de resolver todos los requisitos de prueba. Podrán ahorrar tiempo de desarrollo y probar partes centrales de la aplicación.

Respondida el 17/09/2008 a las 01:38
fuente por usuario Leah

votos
5

Esta es mi opinión sobre ella. Yo diría que la prueba unitaria es la práctica de escribir pruebas de software para verificar que su software real haga lo que debe. Esto comenzó con jUnit en el mundo de Java y se ha convertido en una mejor práctica en PHP también con SimpleTest y phpUnit . Es una práctica básica de Extreme Programming y te ayuda a asegurarte de que tu software siga funcionando según lo previsto después de la edición. Si tiene suficiente cobertura de prueba, puede realizar refactorizaciones importantes, corregir errores o agregar funciones rápidamente con mucho menos temor de presentar 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 OO. La idea básica es crear un script que configure el entorno para su código y luego lo ejercite; usted escribe las afirmaciones, especifica el resultado previsto que debe recibir y luego ejecuta su script de prueba utilizando un marco como los mencionados anteriormente.

El marco ejecutará todas las pruebas contra su código y luego informará el éxito o fracaso de cada prueba. phpUnit se ejecuta desde la línea de comandos de Linux de manera predeterminada, aunque hay interfaces HTTP disponibles para él. SimpleTest se basa en la web por naturaleza y es mucho más fácil de poner en funcionamiento, IMO. En combinación con xDebug, phpUnit puede proporcionarle estadísticas automáticas para la cobertura del código que algunas personas consideran muy útil.

Algunos equipos escriben anzuelos desde su repositorio de subversión para que las pruebas unitarias se ejecuten automáticamente siempre que se realicen cambios.

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

Respondida el 05/08/2008 a las 12:53
fuente por usuario Polsonby

votos
4

Bibliotecas como NUnit , xUnit o JUnit son sólo obligatorio si se quiere desarrollar sus proyectos utilizando el DDT enfoque popularizado por Kent Beck:

Usted puede leer Introducción a Test Driven Development (TDD) o un libro de Kent Beck Test Driven Development: Por ejemplo .

Entonces, si usted quiere estar seguro de sus pruebas cubren una "buena" parte de su código, puede utilizar el software como NCover , JCover , PartCover o lo que sea. Te dirán que el porcentaje de cobertura de su código. Dependiendo de la cantidad que está hábil para TDD, usted sabrá si usted ha practicado lo suficientemente bien :)

Respondida el 14/03/2010 a las 06:22
fuente por usuario PierrOz

votos
3

Creo que el punto de que no entiende es que los marcos de pruebas unitarias como NUnit (y similares) que ayudarán en la automatización de pequeñas a medianas pruebas. Por lo general, se puede ejecutar las pruebas en una interfaz gráfica de usuario (que 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 que lo que falló la prueba y qué es exactamente lo que salió mal muestra. En una prueba normal de la unidad, a menudo se utiliza afirmaciones, por ejemplo Assert.AreEqual(expectedValue, actualValue, "some description")- por lo que si los dos valores no son iguales, verá un error diciendo "alguna descripción: se esperaba <expectedValue> pero era <actualValue>".

Así como una prueba de la unidad conclusión será que el análisis sea más rápido y mucho más cómodo para los desarrolladores. Puede ejecutar todas las pruebas unitarias antes de comprometerse nuevo código para que no rompa el proceso de construcción de otros desarrolladores en el mismo proyecto.

Respondida el 14/03/2010 a las 06:25
fuente por usuario AndiDog

votos
3

Prueba de la unidad es una práctica para asegurarse de que la función o módulo que se va a aplicar se va a comportar como se esperaba (requisitos) y también para asegurarse de cómo se comporta en situaciones como las condiciones de contorno, y una entrada no válida.

xUnit , NUnit , MbUnit , etc., son herramientas que ayudan en la escritura de las pruebas.

Respondida el 14/03/2010 a las 06:22
fuente por usuario Rony

votos
3

Las pruebas unitarias se trata de escribir código que pone a prueba el código de aplicación.

La Unidad de parte del nombre es de 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 - que son los marcos que ayudan con esto. Parte de eso es automatizado corredores de pruebas que indican qué prueba fallan y del cual pasan queridos.

También tienen instalaciones para configurar código común que necesita en cada prueba antes de la mano y derribarla cuando todas las pruebas han terminado.

Usted puede tener una prueba para comprobar que una excepción esperada ha sido lanzado, sin tener que escribir todo el intento de captura bloquear a sí mismo.

Respondida el 14/03/2010 a las 06:19
fuente por usuario Oded

votos
3

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

Respondida el 17/09/2008 a las 01:48
fuente por usuario MetroidFan2002

votos
2

En primer lugar, si hablar de las pruebas unitarias o cualquier otro tipo de pruebas automatizadas (Integración, carga, etc. Pruebas IU), la diferencia clave entre lo que usted sugiere es que está automatizado, repetible y que no requiere ningún recursos humanos para ser consumido (= nadie tiene que realizar las pruebas, que generalmente se ejecuta en una prensa de un botón).

Respondida el 14/03/2010 a las 06:22
fuente por usuario Tomas Vana

votos
2

El desarrollo impulsado por prueba se ha hecho cargo del término Prueba unitaria. Como un viejo temporizador mencionaré la definición más genérica de él.

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

Luego pasaría a las pruebas integradas o del sistema al probar cómo funcionan todos los componentes juntos.

Respondida el 24/08/2008 a las 11:34
fuente por usuario bruceatk

votos
2

La prueba de unidad es la prueba de una unidad de código (por ejemplo, una función única) sin la necesidad de la infraestructura en la que se basa esa unidad de código. es decir, probarlo en forma aislada.

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

Por lo tanto, una prueba unitaria ejercitaría la funcionalidad incluida en la "función" que está probando 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é estás tratando de probar aquí? ¿Que la desviación estándar se calcula correctamente o que los datos se devuelven desde la base de datos?

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

Respondida el 15/08/2008 a las 06:42
fuente por usuario Guy

votos
1

Esto responde a por qué usted debe hacer las pruebas unitarias.


Los 3 vídeos a continuación las pruebas de unidad de cubierta en JavaScript, pero los principios generales se aplican en la mayoría de idiomas.

Prueba de unidad: Minutos Ahora ahorrará Horas Después - Eric Mann - https://www.youtube.com/watch?v=_UmmaPe8Bzc

JS Unidad de Pruebas (muy bien) - https://www.youtube.com/watch?v=-IYqgx8JxlU

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


Ahora estoy aprendiendo sobre el tema por lo que no puede ser 100% correcta y no hay más que lo que estoy describiendo aquí, pero mi entendimiento básico de la unidad de pruebas es que se escribe un código de prueba (que se mantiene separada de su código principal) que llama a una función en el código principal, con entrada (argumentos) que la función requiere y el código comprueba si se vuelve un valor de retorno válido. Si no lo hace volver un valor válido el marco de pruebas de unidad que está utilizando para ejecutar las pruebas muestra una luz verde (todo bien) si el valor no es válido se obtiene una luz roja y luego se puede solucionar el problema inmediatamente antes suelte el nuevo código de producción, sin la prueba es posible que en realidad no ha cogido el error.

Así se escribe pruebas de que el código actual y crea el código de forma que pase la prueba. Meses más tarde que o bien necesitan a alguien para modificar la función en el código principal, ya que el código de prueba anterior que ya había escrito para que la función que ahora se ejecutan de nuevo y la prueba puede fallar debido a que el codificador introduce un error lógico en la función o devolver algo completamente diferente de lo que se supone que la función de volver. Una vez más, sin la prueba en el lugar que el error podría ser difícil de localizar, ya que puede afectar posiblemente otro código, así y pasará desapercibida.


También el hecho de que tiene un programa de ordenador que se ejecuta a través de su código y pone a prueba en lugar de usted hacer manualmente en la página del navegador por página ahorra tiempo (prueba de la unidad de JavaScript). Digamos que se modifica una función que es utilizado por una secuencia de comandos en una página web y funciona muy bien para su nuevo uso previsto. Pero, también vamos a decir por motivo de las discusiones que hay otra función que tiene otra parte de su código que depende de la función que recién modificado para que funcione correctamente. Esta función depende ahora puede dejar de funcionar debido a los cambios que ha realizado en la primera función, sin embargo, sin pruebas en el lugar que se ejecutan automáticamente por el ordenador no se dará cuenta de que hay un problema con esa función hasta que realmente se ejecuta y tú'

Para reiterar, que tiene pruebas que se ejecutan mientras se desarrolla la aplicación va a coger este tipo de problemas, ya que estás de codificación. Al no tener las pruebas en el lugar que tendría que ir manualmente a través de toda su aplicación e incluso entonces puede ser difícil de detectar el error, ingenuamente lo envía hacia fuera en la producción y después de un tiempo un usuario tipo le envía un informe de error (que no será tan bueno como sus mensajes de error en un marco de pruebas).


Es muy confuso cuando escuchan por primera vez del tema y se piensa a sí mismo, ya no estoy probando mi código? Y el código que has escrito está trabajando como se supone que ya "¿por qué necesito otro marco?" ... Si ya está probando su código, pero un equipo es mejor en hacerlo. Sólo tienes que escribir pruebas suficientemente bueno para una función / unidad de código una vez y el resto es atendido por usted por el poderoso CPU en lugar de tener que comprobar manualmente que todo el código sigue trabajando cuando se realiza un cambio en tu codigo.

También, usted no tiene que probar su unidad de código si no quieres pero vale la pena como punto de partida del proyecto / código comienza a aumentar de tamaño ya que las posibilidades de introducir errores aumenta.

Respondida el 18/07/2015 a las 06:34
fuente por usuario Stephen Brown

votos
1

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

¿Cómo podemos hacer pruebas unitarias entonces?

Empiezas pequeño El proyecto en el que recién comencé no tenía pruebas de unidades hasta hace unos meses. Cuando la cobertura era tan baja, simplemente seleccionábamos un archivo que no tenía cobertura y hacíamos clic en "agregar pruebas".

En este momento, estamos en más del 40% y hemos logrado eliminar la mayor parte de la fruta de bajo costo.

(La mejor parte es que incluso con este bajo nivel de cobertura, ya nos encontramos con muchas instancias en las que el código hizo lo incorrecto, y las pruebas lo detectaron. Es un gran motivador para presionar a la gente a que agregue más pruebas).

Respondida el 22/08/2008 a las 07:19
fuente por usuario Adam V

votos
1

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

Hice una toma en TDD recientemente cuando estaba escribiendo una rutina para guardar y restaurar la configuración. Primero, verifiqué que podía crear el objeto de almacenamiento. Entonces, que tenía el método que necesitaba llamar. Entonces, que podría llamarlo. Entonces, que podría pasarle parámetros. Entonces, que podría pasarle parámetros específicos. Y así sucesivamente, hasta que finalmente estuve verificando que guardaría la configuración especificada, permítanme cambiarla y restaurarla para varias sintaxis diferentes.

No llegué al final, porque necesitaba-la-rutina-ahora-maldición, pero fue un buen ejercicio.

Respondida el 22/08/2008 a las 07:10
fuente por usuario SarekOfVulcan

votos
0

Unidad de pruebas y TDD, en general, le permite tener más cortos ciclos de retroalimentación sobre el software que está escribiendo. En lugar de tener una fase de ensayo grande al final de la aplicación, se prueba de forma incremental todo lo que escribe. Esto aumenta la calidad del código mucho, como usted ver de inmediato, en la que podría tener errores.

Respondida el 03/05/2017 a las 06:33
fuente por usuario aap


Aquí podría ser tu PUBLICIDAD