El presentador es el primero (enfoque de software)

El enfoque "presentador primero" es una metodología de desarrollo de software que combina las ideas del patrón de diseño modelo-vista-presentador (MVP), el desarrollo guiado por pruebas y el desarrollo guiado por características .

El presentador se centra primero en transformar cada uno de los requisitos del cliente en una funcionalidad probada y operativa lo más rápidamente posible y con la mayor coherencia posible con el lenguaje de la historia (requisito) del cliente . El lenguaje de la historia o requisito se utiliza para guiar directamente el desarrollo de la funcionalidad, incluso para nombrar los módulos y las llamadas a funciones. Como consecuencia, la implementación de la funcionalidad tiende a representar fielmente el deseo del cliente, con poca funcionalidad superflua o innecesaria. El lenguaje del código fuente también se corresponde estrechamente con las historias del cliente.

El enfoque "presentador primero" se aplica frecuentemente en aplicaciones con interfaz gráfica de usuario . También se aplica con éxito al desarrollo de interfaces de línea de comandos. Además, una ligera variación de este enfoque se ha utilizado eficazmente en software embebido ; en este caso, el patrón de diseño integral se conoce como modelo-conductor-hardware y el enfoque se denomina "conductor primero" .

Cuando se utiliza en aplicaciones con interfaz gráfica de usuario (GUI), este enfoque permite desarrollar la lógica de presentación y la lógica de negocio de la aplicación priorizando las pruebas, independientemente de los elementos visuales en pantalla. De este modo, la gran mayoría de la programación de la aplicación se puede probar mediante pruebas unitarias en un conjunto de pruebas automatizadas. Así, la dependencia de las herramientas de prueba de GUI para realizar pruebas exhaustivas del sistema se reduce a verificar el funcionamiento básico de la interfaz gráfica o incluso se elimina por completo.

El patrón de diseño MVP desacopla los widgets en pantalla, la lógica de presentación y la lógica de negocio. El enfoque "Presenter first" inicia el proceso de desarrollo con el componente presentador de un eje MVP. El desarrollo guiado por pruebas se logra simulando la vista y el modelo y escribiendo pruebas unitarias para el presentador. A continuación, se escribe y revisa el código de producción para el presentador hasta que las pruebas unitarias del presentador se superen. El ciclo se repite para el modelo. Probar la vista unitariamente suele ser poco práctico o imposible; por lo tanto, el código de la vista se deja lo más "ligero" y desprovisto de lógica posible (es decir, la vista es un envoltorio para las llamadas a la biblioteca de widgets y la lógica de presentación está contenida en el presentador). El enfoque "Presenter first" aplicado al patrón MVP permite probar la gran mayoría de la lógica de la aplicación de forma automatizada, dejando solo pruebas de verificación simples en pantalla de la vista y sus widgets.

Los casos de prueba para el presentador se definen a partir de los requisitos o historias del cliente. Un cliente generalmente explica las funcionalidades en términos de sentencias condicionales ("when"), por ejemplo: "Cuando hago clic en el botón 'guardar', el archivo debe guardarse y la advertencia de archivo no guardado debe desaparecer". Las pruebas unitarias y el código del presentador siguen el flujo de estas sentencias condicionales. El presentador espera que se activen eventos de la vista (por ejemplo, al hacer clic en el botón de guardar) y, en respuesta, realiza llamadas a la vista (por ejemplo, ocultar el mensaje de advertencia) y al modelo (por ejemplo, iniciar la operación de guardado del archivo).

Las numerosas funcionalidades de una aplicación pueden hacer que un único eje MVP monolítico resulte difícil de manejar. El presentador propone dividir la aplicación en múltiples ejes MVP. En una aplicación con interfaz gráfica de usuario (GUI), cada pantalla, cuadro de diálogo y widget complejo está representado por un eje MVP (cuyo diseño funcional viene determinado por la historia del cliente). La comunicación entre los ejes agregados se logra mediante conexiones programáticas entre los modelos.

• Alles, Micah; Crosby, David; Erickson, Carl; Harleton, Brian; Marsiglia, Michael; Pattison, Greg; Stienstra, Curt (2006). "Presentador primero: Organización de aplicaciones GUI complejas para el desarrollo guiado por pruebas" (PDF) . Agile : 276–288 . Archivado del original (PDF) el 1 de julio de 2011.
• Crosby, David; Erickson, Carl. "¿Grande, complejo y probado? Solo di '¿Cuándo?'"" (PDF) . Better Software Magazine (febrero de 2007). Archivado del original (PDF) el 1 de julio de 2011.

• Primeros artículos y ejemplos Una colección de recursos de un grupo de los presentadores Primeros creadores
• Parte 1, Parte 2 y Parte 3 : transcripciones de una serie de podcasts en vídeo con Ron Jacobs de ARCast.TV.
• “Múltiples estudios de caso sobre el enfoque «Presenter First»: TDD para el desarrollo de aplicaciones independientes con interfaz gráfica de usuario y complementos para Eclipse”.