Pruebas

Configuración

Probar aplicaciones Mithril.js es relativamente sencillo. La forma más fácil de comenzar es con ospec, mithril-query y JSDOM. Instalarlos es bastante fácil: abre una terminal y ejecuta este comando.

npm install --save-dev ospec mithril-query jsdom

Configurarlos también es relativamente fácil y requiere unos pocos pasos:

1. Agrega un "test": "ospec" a tus scripts npm en tu archivo package.json. El resultado final debería ser similar a esto, posiblemente con campos adicionales relevantes para tu proyecto:

{
  "name": "my-project",
  "scripts": {
    "test": "ospec --require ./test-setup.js"
  }
}

2. Crea un archivo de configuración, test-setup.js, con el siguiente contenido:

var o = require('ospec');
var jsdom = require('jsdom');
var dom = new jsdom.JSDOM('', {
  // Para poder usar `requestAnimationFrame`
  pretendToBeVisual: true,
});

// Define las variables globales que Mithril.js necesita para funcionar.
// Las dos primeras también suelen ser útiles en las pruebas.
global.window = dom.window;
global.document = dom.window.document;
global.requestAnimationFrame = dom.window.requestAnimationFrame;

// Requiere Mithril.js para asegurar que se carga correctamente.
require('mithril');

// Asegura que JSDOM se cierre cuando terminen las pruebas.
o.after(function () {
  dom.window.close();
});

3. Crea un componente, por ejemplo src/my-component.js, con este código:

function MyComponent() {
  return {
    view: function (vnode) {
      return m('div', vnode.attrs.text);
    },
  };
}

module.exports = MyComponent;

4. Y finalmente, crea un archivo de prueba, por ejemplo src/tests/my-component.js, con este código:

var mq = require('mithril-query');
var o = require('ospec');

var MyComponent = require('../my-component.js');

o.spec('MyComponent', function () {
  o('las cosas funcionan', function () {
    var out = mq(MyComponent, { text: 'What a wonderful day to be alive!' });
    out.should.contain('day');
  });
});

Una vez que tengas todo configurado, ejecuta este comando en la misma terminal donde instalaste todo.

npm test

Si todo está configurado correctamente, deberías obtener una salida similar a esta:

––––––
All 1 assertions passed in 0ms

Mejores prácticas

Las pruebas son relativamente sencillas en la mayoría de los casos. Cada prueba generalmente consta de tres partes: configurar el estado, ejecutar el código y verificar los resultados. Pero hay algunas cosas que debes tener en cuenta al realizar pruebas para asegurarte de aprovecharlas al máximo y ahorrar mucho tiempo.

1. En primer lugar, debes escribir tus pruebas lo antes posible en el proceso de desarrollo. No es necesario que las escribas de inmediato, pero al menos debes escribirlas a medida que escribes el código. De esta manera, si las cosas no funcionan como esperabas, invertirás 5 minutos ahora, sabiendo exactamente lo que está sucediendo, en lugar de 5 días seguidos 6 meses después, cuando estés tratando de lanzar esa increíble idea de aplicación que ahora está espectacularmente rota. No querrás encontrarte en esa situación.

2. Prueba la API, prueba el comportamiento, pero no pruebes la implementación. Si necesitas probar que se dispara un evento si ocurre una acción en particular, está bien, puedes hacerlo. Pero no pruebes toda la estructura DOM en tu prueba. No querrás verte obligado a reescribir parte de 5 pruebas diferentes solo porque agregaste una clase simple relacionada con el estilo. Tampoco querrás reescribir todas tus pruebas simplemente porque agregaste un nuevo método de instancia a un objeto.

3. No temas repetirte, y solo abstrae cuando estés haciendo lo mismo decenas o cientos de veces en el mismo archivo o cuando estés generando pruebas explícitamente. Normalmente, en el código, es una buena idea trazar una línea cuando estás repitiendo la misma lógica más de 2-3 veces y abstraerla en una función, pero cuando estás probando, aunque haya mucha lógica duplicada, esa redundancia ayuda a darte contexto al solucionar problemas en las pruebas. Recuerda: las pruebas son especificaciones, no código normal.

Pruebas unitarias

Las pruebas unitarias aíslan partes de tu aplicación, generalmente un solo módulo, pero a veces incluso una sola función, y las prueban como una sola "unidad". Verifican que, dada una entrada particular y un estado inicial, produzca la salida y los efectos secundarios deseados. Todo esto puede parecer complicado, pero te aseguro que no lo es. Aquí hay un par de pruebas unitarias para el operador + de JavaScript, aplicado a números:

o.spec('addition', function () {
  o('works with integers', function () {
    o(1 + 2).equals(3);
  });

  o('works with floats', function () {
    // Sí, gracias IEEE-754 floating point por ser raro.
    o(0.1 + 0.2).equals(0.30000000000000004);
  });
});

Así como puedes hacer pruebas unitarias de cosas simples como esa, también puedes hacer pruebas unitarias de componentes Mithril.js. Supón que tienes este componente:

// MyComponent.js
var m = require('mithril');

function MyComponent() {
  return {
    view: function (vnode) {
      return m('div', [
        vnode.attrs.type === 'goodbye' ? 'Goodbye, world!' : 'Hello, world!',
      ]);
    },
  };
}

module.exports = MyComponent;

Podrías crear fácilmente algunas pruebas unitarias para eso.

var mq = require('mithril-query');
var MyComponent = require('./MyComponent');

o.spec('MyComponent', function () {
  o("says 'Hello, world!' when `type` is `hello`", function () {
    var out = mq(MyComponent, { type: 'hello' });
    out.should.contain('Hello, world!');
  });

  o("says 'Goodbye, world!' when `type` is `goodbye`", function () {
    var out = mq(MyComponent, { type: 'goodbye' });
    out.should.contain('Goodbye, world!');
  });

  o("says 'Hello, world!' when no `type` is given", function () {
    var out = mq(MyComponent);
    out.should.contain('Hello, world!');
  });
});

Como se mencionó antes, las pruebas son especificaciones. Puedes ver en las pruebas cómo se supone que debe funcionar el componente, y el componente lo hace de manera muy efectiva.