¿Cuál es el alcance de una prueba unitaria?

Hablando de definiciones de libros:

Las pruebas unitarias son un proceso de desarrollo de software en el que las partes más pequeñas comprobables de una aplicación, llamadas unidades, se examinan de forma individual e independiente para un funcionamiento adecuado. Las pruebas unitarias a menudo están automatizadas, pero también se pueden hacer manualmente. Este modo de prueba es un componente de Extreme Programming (XP), un método pragmático de desarrollo de software que adopta un enfoque meticuloso para construir un producto mediante pruebas y revisiones continuas.

Fuente: ¿Qué son las pruebas unitarias? – Definición de WhatIs.com

Ahora bien, si hablamos de alcance, generalmente el desarrollador crea una prueba unitaria que demuestra que la funcionalidad básica del sistema está funcionando y la adjunta al ticket / error / error / Nota, etc. Esto puede variar de un sistema a otro, orgs a orgs. La prueba unitaria solo necesita demostrar que si un sistema está diseñado para moverse de un lugar a otro, lo está haciendo. Luego, después de comprender este control de calidad, puede avanzar y explotar la funcionalidad con su experiencia. Por supuesto, el alcance es pequeño pero necesario en las etapas iniciales.

Si miramos desde la perspectiva de QA, él puede dividir el sistema en unidades pequeñas y probarlas según su alcance. Pero iré con la primera definición en el párrafo anterior.

Gracias !

Como siempre, hay algunas variaciones del significado de una Prueba de Unidad. Para mí, me gusta usar este término para nombrar las pruebas que los desarrolladores deben aplicar en sus códigos para comprender si ese fragmento de código se está ejecutando según lo definido, y esta definición es el alcance de la prueba de la Unidad. Si incluye que este fragmento de código debe tratar diferentes situaciones, y puede crear un algoritmo para verificarlo, está bien, pero al final debe cumplir con la especificación técnica que fue el origen del código.

Esta es una definición general, pero “según lo definido” podría ser algo bien definido o algo poco definido.

Las diferencias en el nivel de detalles que tiene una definición, definirán cómo deben escribirse sus pruebas de Unidad.

Los analistas de negocios experimentados escriben mejores casos de negocios y detallarán más las situaciones que el código debe resolver. Los novatos pueden escribir un caso comercial no tan detallado porque no pueden conocer toda la situación que puede conducir a un error comercial.

Los programadores experimentados también pueden dictar una mejor Prueba de Unidad, debido a la experiencia previa también. En realidad, los desarrolladores y evaluadores que trabajan juntos en la definición de las pruebas unitarias probablemente darán como resultado mejores conjuntos de pruebas unitarias.

Además, creo en un proceso de madurez, donde el primer código, aunque bien probado, muestra fallas en la producción, debido a situaciones nuevas e impredecibles que los usuarios finales son “geniales” para crear. Por lo tanto, se encuentran nuevos errores, se corrigen y la Prueba de unidad debe incluir estas nuevas situaciones para evitar sorpresas en el futuro.

Los desarrolladores tienden a probar solo lo que desarrollaron recientemente, donde son muy optimistas sobre el impacto del nuevo código en el código existente. No es el alcance de la prueba unitaria hacer la prueba de regresión, pero es bueno ejecutar algún grado de prueba de regresión si el código existente se modificó durante el desarrollo. Al menos en las funcionalidades directamente afectadas por la modificación.

Para realizar un seguimiento de todo esto, no es fácil, por lo que, dependiendo del tamaño de su código, la cantidad de módulos, etc., uno debe realizar un seguimiento de todas las definiciones, casos comerciales, pruebas unitarias, pruebas del sistema, pruebas de regresión con la administración herramientas que serán responsables de realizar un seguimiento de todos los cambios y el impacto que tiene en su entorno.

Espero que haya ayudado.

Buena suerte.

Por lo general, el cuadro blanco o las pruebas unitarias no son más que pruebas observando el código real del producto y enfocándose en las unidades del código para verificar el estado básico del código. En general, cada vez que se desarrolla el código real de la aplicación / producto, se deben crear las pruebas unitarias correspondientes para demostrar que este código realmente funciona. Esto generalmente lo realizan los desarrolladores de código. Las unidades de código pueden estar en el alcance de la clase o en un único archivo de script con diferentes métodos / funciones. El código de prueba de la unidad puede enfocarse en la prueba de esas funciones / métodos en esa clase / script con varios parámetros para cubrir los escenarios + ve y -ve, las condiciones límite, los tipos de parámetros, los errores, las excepciones, etc. Cada prueba unitaria puede cubrir la función / método único y debe ejecutarse con varios datos de entrada que cubren los escenarios mencionados anteriormente. Esto se llama datos impulsados. Su algoritmo de funciones es el mismo pero probado con varios datos. Use un marco de prueba para generar un informe de aprobación / falla en archivos xml / html / txt. Ejemplos de marcos de prueba basados ​​en Java son los marcos de familia JUnit, TestNG y nUnit. A veces, las pruebas unitarias pueden ir más allá con múltiples clases / scripts funcionales cubiertos en alcance y también tocar otros puntos de integración. Esto es más para las pruebas de unidades de integración (que cubren parte de las pruebas funcionales realizadas por el equipo de control de calidad).

Compartir mi nuevo libro, que cubre más conceptos y también es útil para los profesionales de control de calidad y automatización. Detalles del producto Guía de supervivencia del ingeniero de calidad de software y automatización de Java: conceptos básicos, autoevaluación, preparación de la entrevista (más de 500 preguntas y respuestas) 16 de noviembre de 2016 por Jagadesh Babu Munta (se pueden encontrar más opciones de compra en http: //www.everydayon. com )

Hay más de 500 preguntas y respuestas para facilitar la comprensión de los conceptos y para fines de revisión. Las siguientes son 16 habilidades básicas cubiertas en este libro junto con prácticas / iniciación en un nuevo trabajo. 1. Ciclo de vida del desarrollo de software (SDLC) 2. Conceptos de calidad del software 3. OOPS 4. XML 5. XPath 6. JSON 7. SCM / SCCS (SVN / GIT) 8. Unix / Linux 9. Java y JDBC 10. ANT 11 Maven 12. JUnit 13. TestNG 14. Jenkins / Hudson (CI) 15. Pruebas de aplicaciones web – Selenium 16. Pruebas de servicios web (SOAP & REST API) y SoapUI
Código de muestras de Java: aprender con un ejemplo es una forma rápida de aprender cosas nuevas. El código de muestra de Java ayuda a los desarrolladores y a los ingenieros de control de calidad a sentirse cómodos en la programación de Java. Código de muestra de Selenium: el código de muestra de Selenium ayuda a los ingenieros de control de calidad a aprender la automatización de pruebas de sitios web basados ​​en navegador usando Selenium. Tener ejemplos es una buena manera de entrar rápidamente en la codificación.

Contestaría esto diciendo que la prueba de la unidad debería servir como una validación de que el software está listo para ser probado por los probadores de siguiente nivel, generalmente QA. Si la mitad del departamento de control de calidad encuentra un error antes de que comiencen sus propias pruebas, ese error debería haber sido detectado por las pruebas unitarias.

Por lo general, el propósito de las pruebas unitarias es que los desarrolladores confirmen que su software funciona como se anuncia, lo que significa para mí que se prueba de todas las formas en que será utilizado por el siguiente nivel de software o usuario.

por lo tanto, si el error impide que QA realice sus pruebas, ya debería haber tenido una prueba unitaria que cubriera esa área. Entonces, sí, pruebe todas las formas en que se puede usar el software, tal vez una prueba para cada función, pero generalmente hay mejores formas de cubrir las rutinas multifuncionales.

Si está practicando TDD, que recomiendo, y es bueno en eso, la idea es que cada prueba evalúe un alcance pequeño (comportamiento muy pequeño). Mantiene pequeños alcances a lo largo de su ciclo de desarrollo en función del comportamiento que se le ha pedido que implemente. El comportamiento puede ser en forma de historias, por ejemplo, pequeñas.

El alcance depende totalmente de cómo diseñe en la fase azul de TDD y de cuán pequeño sea cada prueba.

Pero después de haber hecho la prueba primero, me hace pensar en el alcance por adelantado cada pocos minutos durante todo el día. Por eso me gusta TDD. No me ato pensar demasiado, no me abruma tratar de hacer demasiado de una vez; Solo pienso en el siguiente alcance o comportamiento a implementar después de la última (última prueba).

Por lo general, el alcance se basa en una unidad de comportamiento. Sé que no es una oración lo suficientemente buena como para decirle exactamente lo que eso significa, pero tenga en cuenta, a veces eso requiere más de una afirmación por prueba. Probablemente no más de 3 afirmaciones como máximo, pero tenga en cuenta que no siempre será solo una afirmación por prueba. La mitad del tiempo que es su Unidad de Comportamiento la mitad del tiempo que no lo es … nuevamente, dependiendo del tamaño del comportamiento que está probando, espero que sea muy pequeño si está haciendo un buen TDD .

Prueba después, bueno … buena suerte. Ya he descubierto cuáles eran mis alcances como parte de hacer las cosas simplemente practicando el ciclo TDD, que ayuda totalmente a guiarte en esto mismo … y en parte por qué es tan efectivo, uno de sus muchos beneficios. Si pruebas después, ¡es demasiado tarde!

Lo mejor que puede hacer es comenzar a practicar TDD ahora para que pueda obtener beneficios como este que lo guíen a medida que codifica.