tecnico - ¿Por qué Fit/FitNesse?
life fitness usa (3)
Ayuda a reducir la redundancia en regresión y pruebas de errores. Construir repositorio manejable de casos de prueba. Es como construir una vez y usar para siempre.
¿Qué sentido tiene usar Fit / FitNesse en lugar de las pruebas de integración de estilo xUnit? Tiene una sintaxis realmente extraña y muy poco clara en mi opinión.
¿Es realmente solo para que los propietarios de productos escriban pruebas? ¡No lo harán! Es demasiado complicado para ellos. Entonces, ¿por qué debería alguien Fit / FitNesse?
Actualización ¿Es totalmente adecuado solo para pruebas de reglas de negocios?
El objetivo principal es trabajar con personas que no son programadores, a menudo incluso personas que no son técnicas, como los posibles usuarios de una aplicación empresarial, sobre qué aplicación debería hacer y luego ponerla en pruebas. Si bien hacer que las pruebas funcionen es demasiado complicado para ellos, deberían poder discutir tablas de datos de muestra completados en, por ejemplo, Word. Y lo mejor de todo es que, a diferencia de las especificaciones tradicionales, esos documentos viven con su aplicación porque las pruebas automatizadas lo obligan a actualizarlos.
Vea la Introducción a Fit and Fit Workflow de James Shore y siga los enlaces al resto de la documentación si lo desea.
Actualización: ¿ Depende de lo que quiere decir con reglas de negocios? ;-) Algunas personas lo entenderían de manera muy restringida (como en los motores de reglas de negocios, etc.), otras --- muy ampliamente.
Como lo veo, Fit es una herramienta que le permite anotar casos de uso empresarial (como en el dominio) con ejemplos realistas en un documento, que los usuarios finales o expertos en dominios (en algunos dominios) pueden comprender, verificar y discutir. Al mismo tiempo, estos ejemplos están en formato legible por la máquina, por lo que se pueden utilizar para realizar pruebas automáticas. Usted no escribe el documento por su cuenta ni le exige que lo haga. En cambio, es un producto de la colaboración y la discusión que refleja una creciente comprensión de lo que la aplicación va a hacer, en ambos lados. Los ejemplos se enriquecen a medida que avanza y se resuelven más casos de esquina.
Lo que hará la aplicación, no cómo, es importante. Es una forma de especificación funcional. Como tal, es bastante amplio y no está realmente organizado por módulos sino escenarios de uso.
Las pruebas que surgen de los ejemplos probarán el comportamiento externo de la aplicación en aspectos importantes desde el punto de vista empresarial. Sí, podrías llamarlo reglas de negocios. Pero veamos el ejemplo de puntuación de crédito de Diego Jancic, solo con un pequeño giro. ¿Qué pasa si parte del documento de ajuste es 1) enumerar los atributos y sus puntuaciones y luego 2) proporcionar datos del cliente y verificar los resultados? Entonces, ¿cuáles son las reglas de negocio reales? (basado en la tabla de puntuación)? ¿Y cuáles son probados?
Las pruebas Fit / FitNesse parecen más adecuadas para las pruebas de aceptación. Otras pruebas (cuando no te importa la cooperación con clientes, usuarios, expertos en dominios, etc., solo quieres automatizar las pruebas) probablemente serán más fáciles de escribir y mantener de forma más tradicional. xUnit es bueno para pruebas de unidad y api. Cada marco web debe tener alguna herramienta para la prueba de aplicaciones / servicios web integrada en su ciclo de modificar-construir-probar-desplegar, por ejemplo. django tiene su pequeño cliente de prueba. Tienes mucho para elegir.
Y siempre puede escribir su propia herramienta (o, preferiblemente, modificar alguna existente) para que se ajuste mejor (es decir, con un juego de palabras) algunas pruebas en su dominio particular de interés.
Un pensamiento más general. A menudo es mejor (¡no siempre!) Codificar sus pruebas, "reglas de negocios" y casi cualquier cosa, en algún tipo de datos bien definidos que se interpretan mediante un simple código genérico. Entonces, es fácil usar los datos de alguna otra manera: generar documentación, migrar a un nuevo marco de prueba, aplicación de puerto a nuevo entorno / lenguaje de programación, usar para verificar el cumplimiento de algunas reglas externas u otro sistema (solo use su imaginación). Es mucho más difícil extraer dicha información del código, por ejemplo. Pruebas unitarias codificadas simples o reglas de negocio.
Fit almacena casos de prueba como datos. En un formato muy específico debido a cómo está destinado a ser utilizado, pero aún así. Las pruebas específicas de su dominio pueden usar diferentes formatos como CSV simple, JSON o YAML.
La idea es que usted (el programador) defina un formato fácil de entender, como una hoja de Excel. Luego, el propietario del producto ingresa información que es difícil de entender para las personas que no están en el negocio ... y usted simplemente valida que su código funciona como el PO espera que se ejecute Fit. La forma en que se usa en xUnit, se puede usar para los programadores como entrada para información fácil de entender o simple. Si va a necesitar ingresar muchos ejemplos extraños con múltiples campos en su prueba xUnit, será difícil de leer.
Imagine un caso en el que tenga que decidir si otorgar un préstamo a un cliente, en función de la Edad, Casado / Soltero, Cantidad de hijos, Salario, Actividad, ... Como programador, no puede escribir esa información; y un administrador de riesgos no puede escribir una prueba xUnit.