¿De qué sirve usar Fit/FitNesse en lugar de xUnit-style tests de integración? En mi opinión, tiene una sintaxis realmente extraña y poco clara.¿Por qué Fit/FitNesse?
¿Realmente es solo para hacer que los propietarios de los productos escriban las pruebas? ¡No lo harán! Es muy complicado para ellos. Entonces, ¿por qué debería alguien Fit/FitNesse?
Actualización Entonces, ¿es totalmente adecuado solo para pruebas de reglas de negocios?
Todo el punto es trabajar con no programadores, a menudo personas completamente no técnicas como usuarios potenciales de una aplicación comercial, en qué aplicación debe hacer y luego ponerla en pruebas. Aunque hacer que las pruebas funcionen es ciertamente demasiado complicado para ellas, deberían poder analizar las tablas de datos de muestra completadas, por ej. Palabra. Y lo mejor es que, a diferencia de la especificación tradicional, esos documentos viven con su aplicación porque las pruebas automatizadas lo obligan a actualizarlos.
Consulte Introduction To Fit y Fit Workflow por James Shore y siga los enlaces al resto de la documentación si lo desea.
Actualización: Depende de lo que entendemos por reglas de negocio? ;-) Algunas personas lo entenderían muy estrechamente (como en los motores de reglas de negocio, etc.), otros --- muy ampliamente.
Según lo veo, Fit es una herramienta que permite escribir negocios (como en el dominio) casos de uso con ejemplos reales enriquecidos en un documento, que los usuarios finales o expertos de dominio (en algunos dominios) pueden entender, verificar y discutir Al mismo tiempo, estos ejemplos están en formato legible por máquina, por lo que se pueden usar 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 la creciente comprensión de qué aplicación va a hacer, en ambos lados. Los ejemplos se enriquecen a medida que progresas y se resuelven más casos en las esquinas.
Qué aplicación hará, 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 por escenarios de uso.
Las pruebas que provienen de ejemplos probarán el comportamiento externo de la aplicación en aspectos importantes desde el punto de vista comercial. Sí, puede llamarlo reglas comerciales. Pero veamos el ejemplo de puntuación crediticia de Diego Jancic, solo con un pequeño giro. ¿Qué pasa si una parte del documento está 1) enumerando los atributos y sus puntajes y luego 2) proporcionando datos del cliente y verificando resultados, entonces cuáles son las reglas comerciales actuales: tabla de puntaje (atributos y puntajes) o lógica de la aplicación calculando el puntaje para cada cliente (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 le interesa la cooperación con clientes, usuarios, expertos de dominio, etc., solo desea automatizar las pruebas) probablemente serán más fáciles de escribir y mantener de formas más tradicionales. xUnit es bueno para pruebas unitarias y pruebas de API. Cada marco web debe tener alguna herramienta para la aplicación web/prueba de servicio integrada en su ciclo modify-build-test-deploy, por ejemplo. django tiene su pequeño cliente de prueba. Tienes mucho para elegir.
Y usted siempre puede escribir su propia herramienta (o modificar algunas de las existentes) para que se ajuste mejor (juego de palabras) algunas pruebas en su dominio particular de interés.
un pensamiento más en general, es a menudo (no siempre !!!) mejor para codificar sus pruebas, "reglas de negocio" y casi cualquier cosa, en alguna forma de datos bien definidos que es interpretado por algunos simples, pieza genérica de código. Entonces es fácil usar los datos de otra forma: generar documentación, migrar a un nuevo marco de prueba, aplicación de puerto a un nuevo entorno/lenguaje de programación, usar para verificar la conformidad con algunas reglas externas u otro sistema (solo use su imaginación). Es mucho más difícil extraer esa información del código, por ejemplo. pruebas unitarias simples codificadas o reglas comerciales.
Ajuste las casillas de prueba como datos. En un formato muy específico debido a cómo se pretende utilizar, pero aún así. Las pruebas específicas de su dominio pueden usar diferentes formatos, como CSV simple, JSON o YAML (no soy fan de XML, pensé).
Mientras escribía esta actualización (demasiado tiempo), he visto article by Gojko Adzic. Es interesante cómo la gente intenta programar pruebas en Fit/FitNesse como si fuera el lenguaje de programación que IMVHO simplemente derrota el propósito.
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 funcione ya que el PO espera ejecutar Fit. El modo utilizado en xUnit puede ser utilizado por los programadores como una entrada para información simple o fácil de entender. Si va a necesitar ingresar muchos ejemplos raros con múltiples campos en su prueba xUnit, será difícil de leer.
Imagine un caso en el que tiene que decidir si va a dar un préstamo a un cliente, en base a la edad, Casado/individual, la cantidad de niños, de salarios, de actividad, ... Como programador, no se puede escribir que información; y un administrador de riesgos no puede escribir una prueba xUnit.
Ayuda a reducir la redundancia en la regresión y la prueba de errores. Construya un repositorio manejable de casos de prueba. Es como construir una vez y usar para siempre.