Probar su código programáticamente: ¿por el programador u otra persona?

Question

Así que aquí está la situación, una cita de mi jefe: [...] tenemos que centrarnos en la programación. [...] Al final del día, quiero escribir un buen software y no atacar con las pruebas " Esto se dice después de haber tenido 3 meses de una lista desalentadora de errores y recientemente designando un no programador para escribir pruebas web con el marco de selenio.

Mi jefe es muy tímido (no puede ver el beneficio de los costos cuando ralentiza a los desarrolladores). ¿Cuáles son sus opiniones sobre las pruebas web y las pruebas programáticas en general? ¿Deberían ser escritos por el (o A) programador o es importante? ¿Mi pensamiento fue que la parte de escribir un buen software es escribir pruebas? Es un tipo de hombre de la torre de marfil de Microsoft, por lo que los recursos que hayan sido publicados por Microsoft (o buenos artículos en general) en favor de las pruebas por diseño serían útiles.

Answer 1

Esto es lo que hice.

1. De todos modos escribí las pruebas.

2. Escribí el código después de escribir las pruebas.

3. El código era sólido como roca y (en su mayoría) sin errores (a los límites de mis habilidades).

Nunca le dije a nadie que estaba haciendo TDD. A menos que pregunten.

Resulta que TDD es en realidad más rápido que jugar tratando de diseñar algo, codificarlo y esperar que funcione.

Algunas cosas incluyen un paso adicional 0: una "punta tecnológica" para ver cómo funcionan las cosas. Esto es seguido por algún desarrollo de pruebas para ejercer el software real aún no escrito.

Estoy un poco retrasado cuando se trata de comenzar el diseño. Dado que mi diseño es "Diseño y escribe pruebas para ese diseño", mientras que otras personas el diseño es "rascarse con algunas ideas inteligentes pero sin pruebas reales". Algunas personas pueden diseñar bien en papel. No puedo. Pero puedo diseñar pruebas.

En general, estoy bastante por delante cuando se trata de terminar el código. Dado que, cuando termine de codificar, todas las pruebas pasan.

Answer 2

El código completo es un libro que forma parte de la colección de Microsoft. Contiene consejos que defienden la revisión por pares y el cepillado de la prueba de la unidad como concepto. No llega demasiado lejos en detalles con las pruebas unitarias, pero puede calentarlo con la idea y puede explorar más a fondo el tema a partir de ahí.

En última instancia, necesitas a alguien que sea un programador directamente involucrado en la automatización de las pruebas ... quiero decir, eso es por definición.

Las pruebas unitarias son escritas de manera más efectiva por las personas que están más familiarizadas con los subsistemas para los que están escritos, cuando se elige alguien más para escribir pruebas unitarias, les lleva tiempo aumentar, y pueden perder la intención no documentada o clara en el código lo que podría resultar en una peor cobertura. Por otro lado, el propietario del subsistema también puede ser ciego a ciertas deficiencias (¡pero para eso son las revisiones del código de pares!)

---

El resto de esto es realmente una discusión inactiva sobre la ética, pero es importante considerarlo.

A algunas personas les gusta intentar "colarse mierda" a la construcción cuando la gerencia toma decisiones tontas. Esto no solo me inquieta, sino también un poco cauteloso sobre esos programadores. Entiendo la motivación, creo que todos hemos estado allí, pero en última instancia deberías educar en lugar de participar en subterfugio.

La gerencia juega un papel importante en la programación y confían en usted tanto para las estimaciones precisas como para una comprensión general del trabajo que se realiza. Si rellena sus estimaciones para barrer el trabajo extra debajo de la alfombra, ¿eso es realmente algo bueno? Lo que fue una simple mentira se convierte en este engaño elaborado que estás jugando con las personas directamente involucradas en ayudar a su carrera a progresar.

Lo que era un problema con el proceso y la estimación para el trabajo legítimo se ha convertido en un problema de ética pegajosa.

Recomiendo encarecidamente hacer su enfoque planificado para convencer a su gerente para que vean su punto de vista a través de la razón, la lógica y el atractivo de su amor por Microsoft. ;)

A largo plazo, si se encuentra constantemente luchando en la gestión de las decisiones sobre el proceso de programación (que realmente no es su trabajo para tomar decisiones), probablemente sería mejor pulir ese currículum y encontrar un mejor trabajo.

Parte del trabajo de un programador es educar a las personas involucradas que tienen menos experiencia. Explicar eso a su gerente puede ayudar a desglosar algunas de las barreras intelectuales que tiene sobre el tema y suavizarlo para aceptar su consejo sobre el asunto.

Answer 3

Voy por el mundo que para que se "haga", debe haber sido verificado por al menos dos personas. No siempre necesita un probador de software en el equipo si todos en el equipo creen que la calidad del software es el trabajo de todos.

Si desea que sea altamente eficiente, el desarrollador que escribe el código debería escribir las pruebas y alguien las revisa con el código de producción. Si desea ser altamente efectivo, combine con alguien y escriben las pruebas mientras escribe el código en un "TDD emparejado".

Recuerde al gerente que el costo de los errores crece exponencialmente a medida que se encuentra más tarde.

Answer 4

Entiendo de dónde viene tu jefe. Después de todo, los programadores deberían poder producir código que simplemente "funcione". Sin embargo, pruebas voluntad Sucede pase lo que pase, ya sea prueba unitaria, pruebas de integración en su empresa o después de instalar en el cliente. Sin embargo, los errores en cada una de estas etapas tienen diferentes costos y consecuencias, aunque ...

Answer 5

A menudo escuchará que es una buena idea hacer que otras personas prueben su código porque pueden interpretar la especificación de manera diferente. Sin embargo, el beneficio de escribir las pruebas para su propio código es que sabe dónde puede ser defectuoso.

Un enfoque eficiente podría ser una mezcla de ambos: el programador que escribe sus propias pruebas unitarias, centrándose en casos de esquina y alguien más que realiza algunas pruebas funcionales, centrándose en la especificación de nivel superior.

Answer 6

No todas las pruebas son iguales, repasemos algunas:

• Pruebas unitarias / TDD. Es difícil argumentar en contra, especialmente como lo contrario a "No puede ver el beneficio de los costos cuando ralentiza a los desarrolladores", es más rápido. S. Lott repasa los detalles.
• Pruebas de integración enfocadas. Igual que el anterior, es más rápido. No tener que ejecutar una serie de pasos a través de su aplicación totalmente integrada, para averiguar si esa capa muy delgada de código de integración que acaba de escribir está funcionando. Eso es peor cuando consideras que eso se repite tantas veces que tienes que entrar allí, y aún más cuando se vuelve estrechamente acoplado a diferentes procesos.
• Pruebas completas del sistema. Con lo anterior en su lugar, solo desea saber si todas las piezas estaban enganchadas correctamente y si la interfaz de usuario está funcionando como se esperaba. Para lo anterior, necesita una pequeña cantidad de pruebas que se escriban rápidamente; Compare eso con cuántas veces las personas van manualmente (incluido usted mismo) y usted tiene un ganador :). Para más tarde hay algunas cosas que son difíciles de atrapar con pruebas automatizadas, por lo que no enfoca la automatización en ellas.
• Pruebas exploratorias. Todavía se deben hacer, con suerte se piensa lo suficiente antes de que la función esté construida para evitar tener que hacer cambios adicionales en este momento.

Ahora, QA generalmente presenta escenarios adicionales. Esto es bueno, pero es mejor cuando se incluye de manera colaborativa en las pruebas automatizadas.

Un problema real puede ser las habilidades actuales del equipo. Las pruebas unitarias son más difíciles cuanto más acoplado sea el código, esto suele ser peor con el código existente sin pruebas unitarias, pero también hace que sea más difícil avanzar para un desarrollador que no sabe bien cómo diseñar el código libremente acoplado/alto Código de cohesión. Debe hacerse, pero tenga en cuenta esto, ya que el costo irá a algún lado (para los miembros del equipo o la empresa).

Answer 7

Para crear una buena suite de prueba, se necesita bastante esfuerzo; Esto llevará más tiempo de lo esperado.

A este respecto, su jefe tiene razón.

Sin embargo, si planea extender su producto (agregar funciones) o sitio web (agregue páginas y código JavaScript), sin embargo, debe crear la suite de todos modos en un momento posterior.

Answer 8

Podrías señalar que examen de la unidad se ha integrado en el marco .NET desde VS2005.