pruebas de unidades de la vida real para pequeñas empresas y aplicaciones

Question

En estas aplicaciones empresariales típicas, escritas por pequeñas empresas de software (incluso en solitario). ¿Realmente hay algún beneficio en las pruebas unitarias? (Estoy hablando de esas típicas aplicaciones a la medida como una aplicación de facturación automatizada.)

que la mente: Soy no cuestionar los beneficios de las pruebas unitarias (código limpio, mejorar la capacidad de refactorización etc.) pero yo' Estoy cuestionando el ROI para pequeñas aplicaciones de software. De acuerdo, ganará tiempo persiguiendo errores, etc., pero no creo que gane el tiempo suficiente para hacer frente al aumento de tiempo en el desarrollo de las pruebas.

Por favor, me convence de lo contrario, como puedo ver el beneficio en él, pero no para pequeñas aplicaciones de software/empresas por ahora.

PD: ¿Ustedes conocen algún ejemplo de pruebas de unidad de la vida real, como está escrito en aplicaciones comerciales típicas? (Facturación, CRM, etc.)

Answer 1

Veamos,

1. Si su pequeña aplicación se utiliza en una parte muy crítica de la pila de su cliente, entonces es muy importante que se llega lejos con cerca de código que funcione perfectamente.
2. Si esa pequeña aplicación se usa para equilibrar sus cuentas por cobrar, apuesto a que quieren asegurarse de que las fórmulas utilizadas sean correctas. Ningún negocio quiere repartir regalos o "perder" dinero.
3. Si su aplicación expone una API para que pueda expandirse y asimilarse en otra aplicación, querrá pruebas de unidad para verificar que lo hizo bien, su ingeniero lo está atornillando. (Oh, sí, para una pequeña pieza de código de 1000 líneas que realmente me salvó el trasero.)
4. Si su pequeña aplicación pasará a otra persona para mantenerla. Ellos te lo agradecerán.
5. Si obtienes alguna funcionalidad que quieras usar en otra parte de una aplicación más grande, las pruebas pregeneradas de la unidad ahorrarán tiempo y dolor de cabeza. Imagínese un pequeño error que no afecta mucho a su pequeña aplicación al ingresar a una aplicación más grande donde podría causar un daño sustancial.

En resumen, hay una gran cantidad de casos de uso donde pude ver que las pruebas unitarias son rentables incluso para una aplicación pequeña, no trival. Mira el video de klabranche vinculado allí. Excelente.

Answer 2

La única aplicación "pequeña" que puedo pensar que se justificaría al no tener pruebas de unidad es una aplicación de "Hola mundo". De lo contrario, incluso escribir una prueba unitaria para la aplicación más simple será beneficioso.

Answer 3

Así es como lo veo dando sus frutos para pequeñas aplicaciones:

• Sus pruebas son una forma de documentación sobre cómo su aplicación es supone que funciona. Hace la vida más fácil en ti cuando dejas la aplicación solo por un tiempo o el siguiente tipo.
• Sus pruebas son buena cobertura cuando solo necesita hacer ese pequeño cambio que sabe que no romperá nada. Sus pruebas le permitirán saber rápidamente.
• Muchas veces, en pequeñas aplicaciones, la unidad prueba le ahorra tiempo al probar la interfaz de usuario de la aplicación.AKA - Cuantas veces tiene que desconectarse de la aplicación para probar que la pantalla de entrada toma información correcta y escupe la información correcta . Esto no reemplaza las pruebas UI pero ahorra tiempo de prueba en general incluso en aplicaciones pequeñas .
• ¿Con qué frecuencia crecen las aplicaciones pequeñas? En mi experiencia con suficiente frecuencia. Si no inicia las pruebas unitarias anticipadamente, es con más probabilidades de no hacerlo más tarde y/o tarda más tiempo en cubrir el código que no se hizo originalmente. Ahora bien, si sólo podía recordar lo que el código se supone que funciona en todos los casos ..... hmmmm ...
• Es una buena práctica para cuando que sí ven absolutamente el valor en hacer dice en un proyecto más grande y esperemos que sea el mejor para él. :-)
• Las pruebas son una gran manera de ayudar a que ve si tiene una falla de diseño y/o una mejor manera de codificar algo. Las pruebas pueden/son un formulario de diseño y realmente pueden ayudar a uno a ver si algo es un poco torpe/ torpe.

Consulte James Shore's youtube play by play de hacer TDD en una aplicación muy pequeña. Solo verlo pasar y verlo y escucharlo realmente ayuda a mostrar cómo TDD y las pruebas unitarias realmente pueden ser beneficiosas incluso en aplicaciones pequeñas.

Answer 4

Si las pruebas de escritura son tan dolorosas que sientes la necesidad de argumentar en contra de ellas, me pregunto qué tipo de dolor estás pasando y por qué, tal vez hay algo sobre cómo pruebas que no es tan efectivo como podría ser. Cuando he sido responsable de construir incluso pequeños proyectos, las pruebas han sido de gran ayuda.

Antes de que hice las pruebas unitarias que haría las cosas de esta manera:

1) escribir el código para una parte de la aplicación

2) improvisar un arnés de prueba personalizada (lo más probable, añadir un poco de público método static void main a una clase)

3) fijar el código hasta que la prueba funciona, la ejecución manual de la prueba entre las correcciones de

4) pasar a la siguiente parte de código y eliminar o abandonar la prueba

Y, finalmente, me sorprendería cuando las cosas se rompieron en el camino.

Así que escribí pruebas antes, solo eran cosas manuales crudas que no eran reutilizables y no tenían buena cobertura, y terminé tirándolas. Ahora la principal diferencia en lo que hago es escribir el código en bits más pequeños, y guardo las pruebas y puedo continuar ejecutándolas. Y hay muchas menos sorpresas. Para mí no es un obstáculo, es una mejora definitiva.

Answer 5

Las pruebas unitarias y TDD te hacen ir más rápido. Una vez que aprende a hacerlo, puede comenzar un proyecto más rápidamente. Esto asume que tu definición de "hecho" no es "unir algo y enviarlo". Done debe incluir pruebas, soporte, nuevas funciones/mejoras, etc.

El mundo está lleno de pequeñas aplicaciones de consola VB6 y bases de datos de acceso que estaban destinadas a existir durante semanas o meses que ahora mantienen funcionando a las empresas y lo han estado haciendo durante años. Botas de aplicaciones y aplicaciones que "no volverás a tocar" son un mito. No tiene sentido comercial descartar ese trabajo y hacer una aplicación nueva y mejor. El gerente/PM va a ver una propuesta para escribir una nueva aplicación desde cero y decir, "¿No tenemos una aplicación que ya lo hace? Solo modifíquela para que funcione también para esto".

Y así es como nacen las aplicaciones internas de pesadilla. Estoy seguro de que has estado allí. Dudo que este sea tu primer rodeo.

Ahora, si esa aplicación tiene una cobertura de prueba alta (cobertura de funciones y bordes, no solo líneas cubiertas), está muy bien desacoplada (ya que es una condición previa para las pruebas), entonces es fácil de mantener y ampliar.

¿Por qué quiere racionalizar las buenas prácticas de ingeniería con biz-talk como ROI? Si siente dolor al escribir sus pruebas, o necesita más práctica, tiene un código mal diseñado que no se puede probar, o ambas cosas.

Una vez que esté acostumbrado a TDD, o simplemente a GDT (prueba de culpabilidad, pruebas después del código), es muy natural escribir una prueba y escribir un código que sea más comprobable. Esto produce una base de código más limpia que es más modular y desacoplada. Y tienes un alto nivel de confianza en el código que escribiste.

Y descubrirá que no se pierde ese depurador. :)

Answer 6

No sé si mi punto te convencerá o no, pero aquí está.

1. Practicar las pruebas unitarias incluso en aplicaciones pequeñas hará que te sientas más cómodo trabajando con ellas. A veces, es mejor que aprendas o practiques la codificación de aplicaciones pequeñas que proyectos más grandes;

2. Proyecto más pequeño o más grande, solo por su reputación como desarrollador de calidad, la prueba de unidad de su código lo hará menos defectuoso, por no decir, en su mayoría, código impecable. Además, cualquier aplicación merece estar bien desarrollada;

3. Tomando el hábito de probar la unidad cualquier proyecto que desarrolle se convertirá en un mejor programador;

4. Veo TDD como una metodología de trabajo, y como tal, ¿por qué desarrollar con diferentes metodologías cuando el proyecto es más pequeño? Veo, personalmente, no veo ventajas. Utilice las mismas técnicas, enfoques y metodologías en proyectos más pequeños o más grandes, esto encenderá un poco de automaticismo para probar la unidad de cualquier parte de su código, y ya no tendrá que pensar en las pruebas para escribir para la cobertura del código, usted los escribirá por adelantado, lo que resultará en menos omisiones, ya que siempre hace su trabajo de la misma manera;

5. En la situación en la que otro chico tiene que corregir o agregar una función que es más compleja, se asegurará de que tenga que probar sus cosas cuando algo vaya mal, ya que las suyas serán probadas con anticipación. Entonces este tipo puede construir sobre una base sólida, es decir, su código de calidad;

6. La adopción de una forma de desarrollo, como la prueba unitaria de todo lo que hace, pequeña o grande, es para mí como optimizar y factorizar mi código. Utilizando siempre una función que lo hace por mí. Creo un proyecto y llamo a la función para escribir las pruebas unitarias de mi proyecto.Eso es como comenzar un proyecto siempre de la misma manera. Esto crecerá más fácil y más fácil para usted.

Por último, no sé si te convencido de mis puntos de vista, pero al menos espero que esto le traerá buenos puntos de reflexión para que pueda llegar a su propia decisión con respecto a sus necesidades .

¡Que tengas un buen día!

Answer 7

Pruebe estas sencillas preguntas:

• ¿Cómo se prueba su software? ¿A mano? ¿Guiones? Las pruebas unitarias hacen eso (parcialmente).

• ¿Cuánto confías en ti y/o en tus scripts?

• ¿Cuánto tiempo pasas haciendo eso? ¿Un par de segundos? Apuesto más.

• ¿Tiene alguien para hablar de diseño o algoritmos? Las pruebas unitarias lo ayudan a diseñar, simplificar y refactorizar.

• ¿Quién revisa su código? Las pruebas lo harían revisar el código una y otra vez.

Parece casi como que en un proyecto pequeño que tienes más razones para tener pruebas :-)