Plugins en pruebas de Flutter

Casi todos los plugins de Flutter tienen dos partes:

• Código Dart, que proporciona la API que llama tu código.
• Código escrito en un lenguaje específico de la plataforma (o "host"), como Kotlin o Swift, que implementa esas APIs.

De hecho, el código del lenguaje nativo (o host) distingue un paquete de plugin de un paquete estándar.

Construir y registrar la parte host de un plugin es parte del proceso de compilación de la aplicación Flutter, por lo que los plugins solo funcionan cuando tu código se está ejecutando en tu aplicación, como con flutter run o al ejecutar pruebas de integración. Al ejecutar pruebas unitarias de Dart o pruebas de widgets, el código host no está disponible. Si el código que estás probando llama a algún plugin, esto a menudo da como resultado errores como el siguiente:

MissingPluginException(No implementation found for method someMethodName on channel some_channel_name)

Al realizar pruebas unitarias de código que usa plugins, hay varias opciones para evitar esta excepción. Las siguientes soluciones se enumeran en orden de preferencia.

En la mayoría de los casos, el mejor enfoque es envolver las llamadas al plugin en tu propia API, y proporcionar una forma de mockear tu propia API en las pruebas.

Esto tiene varias ventajas:

• Si la API del plugin cambia, no necesitarás actualizar tus pruebas.
• Solo estás probando tu propio código, por lo que tus pruebas no pueden fallar debido al comportamiento de un plugin que estás usando.
• Puedes usar el mismo enfoque independientemente de cómo esté implementado el plugin, o incluso para dependencias de paquetes que no sean plugins.

Si la API del plugin ya se basa en instancias de clase, puedes mockearla directamente, con las siguientes advertencias:

• Esto no funcionará si el plugin usa funciones que no son de clase o métodos estáticos.
• Las pruebas deberán actualizarse cuando la API del plugin cambie.

Si el plugin es un plugin federado, incluirá una interfaz de plataforma que permite registrar implementaciones de su lógica interna. Puedes registrar un mock de esa implementación de interfaz de plataforma en lugar de la API pública con las siguientes advertencias:

• Esto no funcionará si el plugin no está federado.
• Tus pruebas incluirán parte del código del plugin, por lo que el comportamiento del plugin podría causar problemas en tus pruebas. Por ejemplo, si un plugin escribe archivos como parte de una caché interna, el comportamiento de tu prueba podría cambiar según si ejecutaste la prueba previamente.
• Es posible que las pruebas deban actualizarse cuando la interfaz de plataforma cambie.

Un ejemplo de cuándo esto podría ser necesario es mockear la implementación de un plugin utilizado por un paquete del que dependes, en lugar de tu propio código, por lo que no puedes cambiar cómo se llama. Sin embargo, si es posible, deberías mockear la dependencia que usa el plugin en su lugar.

Si el plugin usa platform channels, puedes mockear los platform channels usando TestDefaultBinaryMessenger. Esto solo debe usarse si, por alguna razón, ninguno de los métodos anteriores está disponible, ya que tiene varios inconvenientes:

• Solo las implementaciones que usan platform channels pueden ser mockeadas. Esto significa que si algunas implementaciones no usan platform channels, tus pruebas usarán inesperadamente implementaciones reales cuando se ejecuten en algunas plataformas.
• Los platform channels suelen ser detalles de implementación internos de los plugins. Podrían cambiar sustancialmente incluso en una actualización de corrección de errores de un plugin, rompiendo tus pruebas de forma inesperada.
• Los platform channels pueden diferir en cada implementación de un plugin federado. Por ejemplo, podrías configurar platform channels mockeados para hacer que las pruebas pasen en una máquina Windows, y luego descubrir que fallan si se ejecutan en macOS o Linux.
• Los platform channels no son de tipado fuerte. Por ejemplo, los method channels a menudo usan diccionarios y tienes que leer la implementación del plugin para saber cuáles son las cadenas de claves y los tipos de valores.

Debido a estas limitaciones, TestDefaultBinaryMessenger es principalmente útil en las pruebas internas de implementaciones de plugins, en lugar de pruebas de código que usa plugins.

Quizás también quieras echar un vistazo a Probar plugins.