Introducción

Continuamos con nuestra serie de tutoriales sobre Testing Moderno en Javascript para abordar en esta ocasión una cuestión interesante: la cobertura de aquellos métodos o funciones que estructuramos en nuestras aplicaciones para que sean ‘privados’ siguiendo la filosofía de otros lenguajes de programación orientados a objetos.

Por definición, estos trozos de código deberían ser inaccesibles desde fuera del contexto en el que se han declarado, por lo que a priori, los tests que lanzamos no son capaces de analizarlos. Para solventar este problema no existe una fórmula ‘universalmente aceptada’, por lo que tenemos que recurrir a la que mejor se adapte a nuestra forma de programar.

Veamos en detalle el problema y las soluciones propuestas.

Métodos privados

En Javascript, es habitual contar con métodos privados dentro de nuestros objetos cuyo fin habitual es el de no contaminar el entorno global. Definimos así a estas porciones de código como aquellas no accesibles desde fuera del ámbito (scopes) en que han sido declaradas. Curiosamente, como Javascript no maneja de un modo nativo este tipo de comportamiento como si lo hace por ejemplo Java o PHP dentro de su arquitectura de clases, se ha escrito mucho sobre cómo conseguir ‘emularlo’. En este mismo blog, cuando hemos tratado el tema de los patrones de diseño, hemos ido analizando diversas formas para aislar funciones. La más conocidas por todos, es seguramente la que se deriva del frecuentemente utilizado patrón módulo que ya tratamos en detalle.

Un ejemplo sencillo de esta arquitectura quedaría como sigue:

var myModule = ( function() {
 
    function foo () {
        // private function `foo` inside closure
        return "foo";
    }
 
    return {
        bar: function () {
            // public function `bar` returned from closure
            return "bar";
        }
    }
} () );

Existen muchas variantes de este patrón, cada una con sus particularidades, pero esta resulta clara tras un simple vistazo: vemos una función autoejecutable que devuelve un objeto al contexto global. Dicho objeto tiene como objetivo exponer funciones que serán accesibles de forma directa (desde el contexto global) como en este caso la función ‘bar‘. Esta función ‘bar’ puede sin embargo necesitar dentro de su lógica interna recurrir a otras funciones que no nos interesa que sean accesibles desde fuera, como por ejemplo en este caso, ‘foo‘. La idea es que ‘bar’ puede acceder a ‘foo’ porque están declaradas dentro del mismo contexto, pero cuando se ha evaluado todo, la única función que se devuelve al contexto global es ‘bar’, mientras que ‘foo‘ permanece ‘enterrada’ y por tanto inaccesible.

Este planteamiento puede resultar muy interesante en nuestras aplicaciones porque nos permite ‘ocultar’ parte de la lógica al contexto global. La Programación Orientada a Objetos utiliza esta característica constantemente en sus arquitecturas. Sin embargo, desde la perspectiva del testing, esto nos presenta un problema: mientras que testear ‘bar’ resulta sencillo y trivial porque es accesible, ‘foo’ resulta imposible de alcanzar al no estar expuesto. Es decir, no podemos cubrir con tests la lógica que se encierre ‘foo’ y por tanto quedamos ahí sin cobertura.

NOTA: El tema de la cobertura no lo hemos tratado aún pero aquí puede imponerse por ahora el sentido común: una aplicación debe presentar la mayor cobertura de tests posible, incluyendo por supuesto el análisis de aquellos métodos privados y su correspondiente lógica interna. En un capítulo más adelante trataremos este concepto además de presentar algunas herramientas que nos indican de una forma visual el alcance de nuestros tests con respecto al código que tengamos escrito.

Estrategias agresivas para acceder a los métodos privados

En el mundo del TDD, suele esgrimirse un argumento frente a este escenario: un método privado no debería ser testeado ya que representa una funcionalidad mínima; si se considera que la lógica contenida en uno de estos métodos precisa de tests, tenemos dos posibles soluciones a adoptar: hacer dicha porción de código pública o extraerla a un módulo independiente sobre el que puedan aplicarse estas pruebas.

La primera opción resulta lógica: si un método privado aparece como complejo y requiere de una cobertura de tests, debería resultar natural modificar su ámbito de visibilidad volviéndolo público y así poder acceder desde la capa de tests. Sin embargo, esto conlleva un segundo problema de arquitectura del código: estamos condicionando nuestra organización en función de las pruebas y no del diseño.

La segunda opción, la extracción, es otra alternativa considerable: por lo general, si una funcionalidad dentro de un método privado conlleva un comportamiento complejo que precisa de cobertura, podemos estar ante una clara señal de que ese código debería funcionar como un módulo independiente siendo así en definitiva testeable. No estamos aquí haciendo público el método, sino cogiendo aquella parte más compleja para sacarla a un ámbito al que si podamos acceder con tests. Esta aproximación modular solucionaría la necesidad de realizar tests sobre métodos privados, no altera demasiado el diseño, pero como contrapartida cambia la estructura original de lo que ya hemos desarrollado.

Pese a que ambas soluciones propuestas son viables cuando tenemos que crear tests unitarios para funciones privadas, puede darse el caso en que no estemos en disposición de cambiar la estructura actual, bien por imposición del diseño, del equipo, o cualquier otro.

La solución híbrida

Bajo el supuesto anterior, podemos optar por una solución híbrida entre las dos propuestas anteriores: contar con funciones privadas que, durante el tiempo de desarrollo, se exponen al ámbito público para más tarde, en su paso a producción, convertirlas de nuevo en privadas de forma automática.

Conseguir esto es más sencillo de lo que puede parecer: únicamente debemos referenciar dentro de nuestro objeto a esos métodos privados como parte del API de forma temporal. Acotando esas declaraciones con comentarios o alguna señal visual, más adelante será sencillo eliminarlas manteniendo con ello la visibilidad original esperada. Veamos un ejemplo con el código anterior:

var myModule = ( function () {
 
    function foo () {
        // private function `foo` inside closure
        return "foo";
    }
 
    var api = {
        bar: function () {
            // public function `bar` returned from closure
            return "bar";
        }
    }
 
    /* test-code */
    api._foo = foo;
    /* end-test-code */
 
    return api;
} () );

Aquí podemos ver cómo el esquema básico no se ha modificado sustancialmente: tenemos una función autoejecutable que devuelve un objeto ‘api‘. Este objeto, la API propiamente dicha, lleva asociada el método ‘bar‘ como público. En el ámbito privado quedaría ‘foo‘, en principio inaccesible desde fuera de su contexto. Sin embargo, al asociar esta función directamente al objeto ‘api‘ tal y como vemos al final del código estamos permitiendo su acceso temporal desde fuera.

/* test-code */
api._foo = foo;
/* end-test-code */

El guión bajo inicial indicaría según las convenciones, que estamos ante un método privado susceptible de cambio.

En este contexto, tanto ‘bar‘, como ‘_foo‘ están expuestos como métodos públicos del objeto ‘api‘ y, por tanto, son ‘testeables’.

La estrategia final pasaría por eliminar este tipo de código en el paso final a producción bien a mano o, mucho mejor, mediante alguna herramienta de CI (Integración Continúa) como Grunt. Básicamente, en nuestro ejemplo, hemos modificado nuestro API dentro de un bloque de comentarios que nos sirven de delimitadores. Una vez completo el desarrollo, únicamente tendríamos que preocuparnos de indicar a nuestra herramienta automatizada que elimine dicho bloque salvaguardando así la estructura original de nuestro código.

Cuando tratemos el tema de la automatización, retomaremos este ejemplo para ver cómo podríamos eliminar ese ‘chivato’ que hemos colocado al final de nuestro objeto y que ‘revela’ las funciones que tendrían que ser privadas. De momento, la idea es disponer de la capacidad de acceder a ellas manteniendo diseño y código prácticamente inalterables.

Conclusión

Dentro de una dinámica TDD, es importante que cada línea de código efectivo que escribamos esté respaldada por un test que verifique su correcto comportamiento. Esto resulta relativamente sencillo de cumplir cuando todo el código es accesible desde cualquier punto de la aplicación, o lo que es lo mismo, cuando desde el contexto global se puede alcanzar a toda y cada una de las funciones que hemos programado. Sin embargo, en el mundo real, una aplicación moderna ‘esconde’ parte de su lógica dentro de estructuras y patrones de diseño que se han diseñado precisamente para cumplir esa labor: crear flujos lógicos donde solo quede finalmente expuesto de forma pública lo necesario mientras que toda la lógica interna queda oculta.

Este planteamiento, tan interesante desde el punto de vista de arquitectura del software, resulta sin embargo insalvable cuando queremos practicar los tests. Si un código es inaccesible para el API público de la aplicación, también lo es para el test. Por ello, hemos presentado dos estrategias (agresivas) y un híbrido final con el que salvar este punto, quedando a la elección del desarrollador (o equipo), aquel que mejor se adapte a su forma de trabajo.