¿Qué significa para usted la prueba unitaria?

Question

G'day,

Estoy trabajando con un grupo de desarrolladores extraterritoriales que han estado usando el término pruebas unitarias bastante poco.

Su documento de control de calidad se refiere a escribir pruebas unitarias y luego realizar pruebas unitarias del sistema.

Esto no se alinea con mi interpretación de qué unidad de prueba es en absoluto.

Estoy acostumbrado a que las pruebas unitarias sean una prueba o conjunto de pruebas que se usan para ejercitar una sola clase, generalmente como una caja negra. La clase sometida a prueba puede requerir que la implementación incluya otras clases, pero en general es una clase única la que está siendo ejercida por la (s) prueba (s) de la unidad.

Entonces usted tiene sistema de pruebas funcionales, pruebas Intergration, pruebas de aceptación, etc.

que quiero saber es esto un poco pedante por mi parte? ¿O es esto en lo que piensas cuando te refieres a pruebas unitarias y pruebas unitarias?

Editar: Rob Wells. Necesito aclarar que abordar estas pruebas desde una perspectiva de caja negra es solo un aspecto. Al usar objetos simulados para verificar comportamientos internos, realmente está probando desde una perspectiva de recuadro blanco porque sabe lo que quiere que suceda dentro de la caja.

Answer 1

Intento implementar pruebas unitarias para probar solo un método. y hago un esfuerzo para crear clases "simuladas" para las clases dependientes y los métodos utilizados por el método que estoy probando ... ... para que el ejercicio del código en ese método no llame código en otros métodos la prueba unitaria no debe ser "Prueba" (hay otras pruebas unitarias para esos métodos) De esta manera, una falla en la prueba de la unidad indica de manera confiable una falla en el método que la prueba de la unidad está probando ...

Mock classes están diseñados para "simular" la interfaz y el comportamiento de clases dependientes para que el método que estoy probando pueda llamarlas y se comportarán de una manera estándar y bien definida de acuerdo con los requisitos del sistema. Para que este enfoque funcione, las llamadas a dichas clases dependientes y a sus métodos deben realizarse en una interfaz bien definida, de modo que el proceso "probador" pueda "inyectar" la versión Simulada de la clase dependiente en la clase que se está probando en su lugar. de la versión de producción real ... Esto es como un patrón de diseño común denominado "Inyección de dependencia" o "Inversión de control" (IOC)

Existen varias herramientas de terceros en el mercado para ayudarlo a implementar este tipo de patrón. Uno que he oído hablar se llama "Rhino-Mock" o algo así ...

Edit: Rob Wells. @Charles. Gracias por esto. Me olvidé de usar objetos simulados para reemplazar por completo el uso de otras clases, excepto la que está bajo prueba.

Un par de otras cosas que me he acordado después de mencionar los objetos de imitación es que:

• que pueden ser utilizados para simular errores siendo devueltos por las clases incluidas.
• se pueden usar para plantear excepciones específicas para verificar el manejo de excepciones en la clase bajo prueba.
• se pueden usar para simular elementos donde los costos de configuración son altos, p. un gran back-end SQL DB.
• se pueden usar para verificar el contenido de una solicitud entrante.

Para obtener más información, echar un vistazo a el papel de Martin Fowler llamado "Mocks Aren't Stubs" y el artículo de Los programadores pragmáticos "Mock Objects"

Answer 2

Las pruebas unitarias generalmente son utilizadas por los desarrolladores para probar secciones aisladas de código. Cubren casos fronterizos, casos de error y casos normales. Tienen la intención de demostrar la exactitud de un segmento limitado de código. Si todas las pruebas de su unidad pasan, entonces ha demostrado que sus segmentos aislados de código hacen lo que se supone que deben hacer.

Cuando realiza pruebas de integración, está buscando casos de extremo a extremo, para ver si todos los segmentos que pasaron las pruebas unitarias funcionan juntos. La prueba funcional verifica si el código cumple con los requisitos especificados. La prueba de aceptación es realizada por los usuarios finales para ver si aprueban el producto final.

Answer 3

He oído hablar de técnicas en las que muchas de las pruebas unitarias se realizan primero, y el desarrollo se hace alrededor de ellas. Alguien acaba de comentar diciendo que esto es "Desarrollo impulsado por prueba" - TDD (gracias a Elie).

Pero si se trata de una operación costa afuera que posiblemente le cobre más dinero porque están pasando el tiempo haciendo estas pruebas unitarias, entonces tendría cuidado. Obtenga una segunda opinión de alguien con experiencia en pruebas unitarias que verifique que realmente está haciendo lo que dice.

Desde mi entendimiento, las pruebas unitarias agregarán un poco más de tiempo a cualquier proyecto de desarrollo, pero por supuesto pueden ofrecer un control de calidad. No obstante, este es el tipo de control de calidad que me gustaría con un proyecto interno. Esto puede ser algo que la compañía offshore arroja para darte un poco de calor.

Answer 4

Wikipedia parece sugerir que la prueba unitaria se trata de probar la menor cantidad de código que sería un método en una clase en el caso de la programación OO.

Algunos pueden tener un término más general de lo que quieren decir con pruebas unitarias, donde algunos pueden pensar en algunas pruebas de integración como pruebas unitarias donde la unidad es una mezcla de componentes.

Answer 5

Esto es casi una repetición de la pregunta "What is a 'Unit'?".

"Unidad" se puede definir de forma flexible. Si su documento no tiene una definición de "unidad", deberá aclararlo.

Puede ser que piensen en la unidad como un gran conjunto de código. Cuál no es la definición más deseable.

Aunque estoy de acuerdo en que tiene varias capas de pruebas (unidad, módulo, paquete, aplicación), también creo que gran parte de esto se puede hacer con herramientas de prueba de unidades. Llevando a "¿qué es una unidad?" preguntas que surgen todo el tiempo.

La unidad depende del contexto. Para un desarrollador individual, la unidad debe ser Clase. A veces, también significará módulo o paquete.

Para un equipo, sin embargo, su unidad puede ser un paquete o una aplicación completa.

Answer 6

¿Qué importa lo que pensemos? El problema aquí es su infelicidad con los términos que usan en el documento. ¿Por qué no lo discutes con ellos?

Answer 7

No hay ninguna razón por la cual las pruebas unitarias no pueden abarcar múltiples clases, o incluso submódulos, siempre que la prueba trate solo una operación comercial consistente. Piense en "calculateWage", un método de BO que usa diferentes estrategias para calcular el salario de una persona. Esa es una prueba de unidad en mi opinión.

Answer 8

Existe una diferencia entre el proceso que utiliza para probar y la tecnología que se utiliza para sustentarlo. Los diversos marcos utilizados para las pruebas unitarias generalmente son muy flexibles y se pueden usar para probar unidades pequeñas de código, unidades grandes e incluso probar procesos completos. Esta flexibilidad puede generar confusión.

Mi recomendación es que cualquiera que sea la metodología o el proceso específico que adopte, segregará las diversas pruebas unitarias en ensamblajes o módulos distintos. La disposición exacta depende de su código y la organización de su compañía.

El efecto acumulativo del uso del marco de Prueba de unidades es que gran parte de las pruebas del código se realizan de forma automática. Adoptados correctamente, los desarrolladores pueden evaluar los cambios en el código de código mejor sin tener que pasar por un proceso completo de Q & A. En cuanto al proceso Q & A, hace que su tiempo sea más productivo ya que la calidad del código que sale del desarrollo debería ser mayor.

Comprender que no es la respuesta a todos los problemas de calidad es solo una herramienta útil como la otra que utiliza.

Answer 9

hay una vista tradicional de http://en.wikipedia.org/wiki/Software_testing como parte de http://en.wikipedia.org/wiki/Software_engineering. pero me gusta la idea de una prueba de unidad ágil: una prueba es una prueba de unidad ágil si es lo suficientemente rápida para que los programadores siempre lo ejecuten.

Answer 10

Hace diez años, antes del uso actual de "pruebas unitarias" como pruebas escritas en código, la misma designación se aplicaba a las pruebas manuales. Trabajé para una empresa de desarrollo de software con un proceso de desarrollo de software muy formalizado. Tuvimos que escribir "pruebas de unidad" antes de escribir cualquier código. En esa época, las pruebas unitarias se escribieron en un documento de texto (como en Word). Describieron los pasos exactos que el usuario debía seguir para usar la aplicación. Por ejemplo, describieron la entrada exacta a escribir en la página para configurar un nuevo cliente. O bien, el usuario debía buscar un producto en particular y ver que la información mostrada coincidiera con el documento de prueba. Entonces, la prueba fue una secuencia de comandos que el probador siguió, donde también registraron los resultados. Cuando llegó la nueva encarnación de las pruebas unitarias, fue confuso por un tiempo tratar de averiguar si se referían a las viejas pruebas humanas o las nuevas pruebas codificadas.

Answer 11

Una prueba de unidad es la pieza más pequeña y única de confianza que puede obtener en el camino hacia el final. Eso es lo que importa, construyendo iterativamente un escudo contra la regresión y la desviación de especificación, y no cómo lo integra realmente a su arquitectura orientada a objetos.

Answer 12

que llevan un grupo de equipo de alta mar también. Supuestamente tenemos un conjunto de pruebas unitarias ... pero no significa mucho. :) Así que confiamos mucho más en el funcional y probadores de calidad. El problema heredado con las pruebas unitarias es que tienes un conocimiento perfecto de los funcionales y confías en los desarrolladores. En el mundo real, eso es difícil de asumir ...

Answer 13

Pruebas unitarias: Las pruebas se realizan a una unidad o a una pieza de software más pequeña. Hecho para verificar si satisface su especificación funcional o su estructura de diseño prevista.