idea general de la unidad de prueba

Question

Esta pregunta puede ser un poco vaga, pero aquí va. Acabo de comenzar las pruebas unitarias y parece que estoy luchando con la noción básica.

Estoy probando una función que comprueba si existe un registro en la base de datos. Si no, agrega el nuevo registro y devuelve su ID. Entonces la función es simple de escribir. Y la única forma en que puedo pensar para probarlo es mediante el uso del marco burlón para verificar que las propiedades/métodos correctos se hayan llamado el número correcto de veces.

La parte con la que estoy luchando es que todo lo que he leído habla sobre escribir pruebas primero y luego sobre la función. Pero siento que solo funcionará si escribo la función primero y luego escribo pruebas que reflejan el funcionamiento interno de las funciones.

¿Existe realmente una regla de oro para esto?

¿Y cuánto debería estar probando la lógica transaccional básica de todos modos?

Answer 1

Tal vez si quieres desarrollar en este nivel, primero puedes escribir el contrato del método y luego la prueba dependiendo del contrato. Es importante que su método se comporte como se define en el contrato, porque esto es lo que otros desarrolladores esperarán. Especialmente los casos de borde (excepciones, etc.) deben probarse.

Si va a cambiar su contrato mientras desarrolla el método, bueno, eso no es bueno. Debido a que no ha planeado bien su software y también puede reescribir sus pruebas =)

Las pruebas son importantes porque cuando realiza cambios en el código, más adelante podrá detectar los errores más fácilmente con las pruebas guardadas, cuando aplastando algo, tratando de desarrollar algo nuevo.

Answer 2

Por lo que yo sé, yo diría que siempre debe tener en cuenta cómo va a probar la función, pero primero codifique la función. Esto le permitirá localizar partes críticas y eventuales errores que podrían ocurrir. También podría probar las salidas/entradas de su función y asegurarse de que corresponden a los resultados deseados. Las pruebas de Black Box funcionan bien con esta prueba de unidad de precodificación.

También he estado luchando con esta idea de escribir pruebas unitarias antes de codificar su método real. Por favor, tenga en cuenta que solo soy un estudiante y esta es solo mi opinión.

creo que sirve, espero que estoy bien :)

Answer 3

La parte Estoy luchando con decir que en todas partes he leído nunca habla de cómo escribir pruebas primero y luego la función. Pero siento que solo funcionará si escribo la función primero y luego escribo pruebas que reflejan el funcionamiento interno de las funciones.

Parece que está sufriendo el problema común de huevos de gallina con test-driven development (TDD). No sabe lo que quiere probar hasta que tenga el código, y cree que no puede hacer TDD a menos que escriba pruebas antes de codificar.

Esto es realmente un caso de Bloque del diseñador (tm). Al igual que el bloqueo del escritor, a menudo es bueno resolverlo mediante la codificación, incluso si arrojas todo ese código.

Hackear un prototipo, y luego pretender que no existe.(no lo envíe :) Este prototipo debe explorar los conceptos con los que no estaba familiarizado, o no tenía suficiente información para comenzar a diseñar. Debería familiarizarte con el problema para que puedas comenzar a diseñar.

Después de que tenga una prueba de concepto, revise el código de la manera más conveniente. En su revisión, determine cómo quiere que sea la interfaz pública, qué patrones arquitectónicos se adaptan mejor al programa y qué dependencias deben aislarse unas de otras (y burlarse de ellas en sus pruebas). Tome notas o presente requisitos en su software de planificación de proyectos/elementos de trabajo en su software de seguimiento de proyectos.

Si tiene problemas para identificar estas cosas en su revisión, debe intentar reclutar a otros programadores (y posiblemente diseñadores/personas que identifiquen los requisitos de su empresa) para que lo ayuden. Un mentor de código puede ser una buena idea.

De esa revisión, usted debería poder comenzar a codificar sus pruebas. O podría comenzar a escribir una especificación técnica: este consejo se aplica igualmente bien a ambos.

(si está trabajando en un equipo, reuniendo los requisitos y obtener retroalimentación de los usuarios/realizar UATs también es necesaria, pero que podría ser el trabajo de otro)

Editar

Tenga en cuenta que este es solo un enfoque para lidiar con este problema. Otra es simplemente relajar cualquier idea puritana sobre cómo debería funcionar TDD, y simplemente desarrollar sus pruebas en paralelo con su código. Verifíquelos al mismo tiempo.

También está perfectamente bien hacer pruebas unitarias sin TDD. Las pruebas unitarias confieren más beneficios que solo codificar su diseño y requisitos. También son una gran ayuda cuando agrega nuevas características o corrige errores (pruebas de regresión) o cuando transporta su código.

Answer 4

¿Y cuánto debería estar probando la lógica transaccional básica de todos modos?

Según mi experiencia, cuanto más pruebas hagas, más feliz serás.

Al probar la lógica transaccional básica obtendrá experiencia con sus clases y cómo interactúan, y le dará una idea de su velocidad, e incluso cómo funciona realmente la lógica transaccional básica.

Le ayudará a ser mejor escribiendo casos de prueba, porque la práctica hace al maestro.

Y más tarde, quién sabe, le ayudará a detectar un error cuando actualice su base de datos, o cambie las bases de datos por completo.

Answer 5

Existen buenas razones para escribir primero las pruebas:

1. a asegurarse de que su prueba falla realidad. Si primero escribe su implementación y luego la prueba, la prueba pasará, pero no sabrá si realmente funciona. ¡Puede haber un error en la prueba! Si primero escribe la prueba, puede ejecutarla y asegurarse de que falle.
2. Si solo escribe el código que es necesario para pasar las pruebas que tiene, obtendrá una cobertura de código muy alta.
3. Si primero escribe pruebas, incluidos todos los simulacros y falsificaciones, obtendrá una mejor comprensión de los requisitos. Al burlarse de una API determinada, es posible que descubra que hay alguna información adicional que necesita para realizar una llamada API o algo así.
4. Motivación. Si ya tiene un código escrito, es muy fácil ir a Naaah, no necesito probar . Incorrecto. Si vas al revés, esto todavía es posible, pero el umbral de inhibición es más alto.

En general, puede sentirse duro, pero la recompensa merece la pena.

Answer 6

Trataré específicamente de responder a su pregunta sobre la prueba de lógica básica de transacciones. La mayoría de las veces escribo pruebas unitarias para las unidades que están más arriba en la jerarquía. Por ejemplo, en una configuración básica de modelo-vista-controlador, mis pruebas unitarias están probando los controladores, no el DAL subyacente. ¿Por qué? Porque I asume que cuando un controlador pasa las pruebas, las capas debajo del controlador también funcionarán bien.

Hay una excepción, sin embargo, para bibliotecas compartidas. Las bibliotecas que se comparten en muchos proyectos obtendrán sus propias pruebas unitarias, por ejemplo para garantizar la estabilidad de la API.

Además, observe las pruebas de su unidad como otra aplicación en su proyecto. Asegúrate de no codificar con código c/p, no tires muchos accesorios de prueba juntos, pero tómate tu tiempo para diseñar una buena estructura que sea extensible. Le ahorrará mucho tiempo en la función.