Pruebas de Simulación HTTP en Node.js

Spanish (Español) translation by James Kolce (you can also view the original English article)

Final product image — What You'll Be Creating

Las pruebas de simulación HTTP te permiten implementar y probar una función incluso si los servicios dependientes no están implementados todavía. También, puedes probar los servicios que ya se han implementado sin realmente llamar a estos, en otras palabras puedes probarlos sin conexión. Debes analizar las necesidades de tu negocio para la aplicación primer y escribirlos como escenarios en tus documentos de diseño.

Digamos que estás desarrollando un cliente API en NodeJS para un servicio de medios de comunicación (no hay ningún servicio de este tipo en la vida real, solo para pruebas) de música, vídeo, fotos, etcetera. Habrá un montón de características en este API, y puede haber necesidad de algunos cambios de vez en cuando.

Si no tienes pruebas para esta API, no sabrás qué problemas puede causar. Sin embargo, si tienes pruebas para esta API, puedes detectar problemas mediante la ejecución de todas las pruebas que has escrito. Si estás desarrollando una nueva característica, necesitas agregar casos de prueba especificados para ello. Puedes encontrar una API que ya se han implementado en este repositorio de GitHub. Puedes descargar el proyecto y ejecutar npm test para poder ejecutar todas las pruebas. Vamos a continuar con la parte de la prueba.

Para una prueba de simulación de HTTP, utilizamos nock, que es una biblioteca de simulación y expectativas HTTP y para NodeJS. En las pruebas de simulación de HTTP, puedes aplicar el siguiente flujo:

Definir una regla de simulación de solicitud/respuesta.
Crear una prueba y utilizar su función en la prueba.
Comparar los resultados esperados con los resultados reales en la devolución de llamada de prueba.

Prueba Simple

Pensemos en un cliente API de media. Digamos que llamas la función musicsList mediante el uso de una instancia de la biblioteca Media como a continuación:

var Media = require('../lib/media');
var mediaClient = new Media("your_token_here");
mediaClient.musicsList(function(error, response) {
    console.logs(response);    
})

En este caso, obtendrá una lista de música en la variable de respuesta mediante una petición a https://ap.example.com/musics dentro de esta función. Si quieres escribir para esto, necesitas simular las peticiones para hacer tus pruebas de funcionamiento offline. Vamos a simular esta petición en nock.

describe('Music Tests', function () {
    it('should list music', function (done) {
        nock('https://api.example.com')
            .get('/musics')
            .reply(200, 'OK');
        mediaClient.musicList(function (error, response) {
            expect(response).to.eql('OK')
            done()
        })
    })
})

describe('Musics Tests', function()... es para agrupar las pruebas. En el ejemplo anterior, estamos agrupando pruebas relacionadas a música en el mismo grupo. it('should list music', function(done)... es para probar acciones especificas en funciones relacionadas con música. En cada prueba, el callback done es provisto para revisar el resultado de la prueba dentro de la función callback de la función real. En la solicitud simulada, asumimos que se responde OK si llamamos a la función de musicList. Se compara el resultado esperado y real dentro de la función de devolución de llamada.

Igualación de un Archivo

Puedes definir los datos de solicitud y respuesta dentro de un archivo. Puedes ver el ejemplo para igualar los datos desde un archivo de respuesta.

it('should create music and respond as in resource file', function (done) {
            nock('https://api.example.com')
                .post('/musics', {
                    title: 'Smoke on the water',
                    author: 'Deep Purple',
                    duration: '5.40 min.'
                })
                .reply(200, function (uri, requestBody) {
                    return fs.createReadStream(path.normalize(__dirname + '/resources/new_music_response.json', 'utf8'))
                });
            mediaClient.musicCreate({
                title: 'Smoke on the water',
                author: 'Deep Purple',
                duration: '5.40 min.'
            }, function (error, response) {
                expect(JSON.parse(response).music.id).to.eql(3164495)
                done()
            })
        })

Cuando se crea una pieza musical, la respuesta debe coincidir con la respuesta del archivo.

Encadenamiento de Peticiones Simuladas

También puedes encadenar una solicitud simulada en un ámbito como abajo:

it('it should create music and then delete', function(done) {
            nock('https://api.example.com')
                .post('/musics', {
                    title: 'Maps',
                    author: 'Maroon5',
                    duration: '5:00 min.'
                })
                .reply(200, {
                    music: {
                        id: 3164494,
                        title: 'Maps',
                        author: 'Maroon5',
                        duration: '7:00 min.'
                    }
                })
                .delete('/musics/' + 3164494)
                .reply(200, 'Music deleted')

            mediaClient.musicCreate({
                title: 'Maps',
                author: 'Maroon5',
                duration: '5:00 min.'
            }, function (error, response) {
                var musicId = JSON.parse(response).music.id
                expect(musicId).to.eql(3164494)
                mediaClient.musicDelete(musicId, function(error, response) {
                    expect(response).to.eql('Music deleted')
                    done()
                })
            })
        })

Como se puede ver, pueds simular la creación musical y la respuesta primero y luego la eliminación de música y finalmente la respuesta a otros datos.

Igualación de Cabeceras de Solicitud

En el cliente de media, Content-Type: aplication/json se proporciona en los encabezados de solicitud. Puedes probar un encabezado específico como este:

it('should provide token in header', function (done) {
    nock('https://api.example.com', {
        reqheaders: {
            'Content-Type': 'application/json'
        }
    })
        .get('/musics')
        .reply(200, 'OK')

    mediaClient.musicList(function(error, response) {
        expect(response).to.eql('OK')
        done()
    })

})

Cuando haces una solicitud a https://api.example.com/musics con un encabezado Content-Type: aplication/json, será interceptado por la simulación HTTP de nock de arriba, y serás capaz de probar el resultado esperado y real. También puedes probar cabeceras de respuesta de la misma manera sólo declarando el encabezado de respuesta en la sección de respuesta:

it('should provide specific header in response', function (done) {
    nock('https://api.example.com')
        .get('/musics')
        .reply(200, 'OK', {
            'Content-Type': 'application/json'
        })

    mediaClient.musicList(function(error, response) {
        expect(response).to.eql('OK')
        done()
    })

})

Contestar con Encabezados Predeterminados

Puedes especificar encabezados de respuesta predeterminados para las solicitudes en un ámbito mediante el uso de defaultReplyHeaders como sigue:

it('should provide default response header', function(done) {
    nock('https://api.example.com')
        .defaultReplyHeaders({
            'Content-Type': 'application/json'
        })
        .get('/musics')
        .reply(200, 'OK, with default response headers')

    mediaClient.musicList(function(error, response) {
        expect(response).to.eql('OK, with default response headers')
        done()
    })
})

Al llamar a la API, encontrarás por defecto encabezados de respuesta en la respuesta, incluso si no se especifica.

Operaciones de HTTP

Las operaciones de HTTP son los fundamentos de las peticiones del cliente. Puedes interceptar cualquier operación de HTTP mediante el uso de intercept:

1	scope('https://api.example.com')
2	.intercept('/musics/1', 'DELETE')
3	.reply(404);

Cuando intentas eliminar música con id 1, responderá 404. Puedes comparar tu resultado real con 404 para comprobar el estado de prueba. También puedes usar GET, POST, DELETE, PATCH, PUT y HEAD de la misma manera.

Repetición de la Respuesta

Normalmente, las peticiones simuladas realizadas mediante el uso de nock están disponibles por la primera vez. Puedes hacerlas disponible tanto como quieras así:

var scope = nock('https://api.example.com')
                .get('/musics')
                .times(2)
                .reply(200, 'OK with music list');
                
http.get('https://api.example.com/musics'); // "OK with music list"
http.get('https://apiexample.com/musics'); // "OK with music list"
http.get('https://apiexample.com/musics'); // "Real response from api"

Estás limitado a hacer dos peticiones como peticionnes de HTTP simuladas. Cuando haces pedidos de tres o más, automáticamente harás una solicitud real a la API.

Puerto Personalizado

También puedes proporcionar un puerto personalizado en tu URL de la API:

it('should handle specific port', function(done) {
    nock('https://api.example.com:8081')
        .get('/')
        .reply(200, 'OK with custom port')
    request('https://api.example.com:8081', function(error, response, body) {
        expect(body).to.eql('OK with custom port')
        done()
    })
})

Filtrado de Alcance

El filtrado de alcance se vuelve importante cuando deseas filtrar el dominio, el protocolo y el puerto para tus pruebas. Por ejemplo, la siguiente prueba te permitirá simular las solicitudes que tienen subdominios como API0, API1, API2, etcetera.

it('should also support sub domains', function(done) {
    nock('http://api.example.com', {
        filteringScope: function(scope) {
            return /^http:\/\/api[0-9]*.example.com/.test(scope);
        }
    })
        .get('/musics')
        .reply(200, 'OK with dynamic subdomains')

    request('http://api2.example.com/musics', function(error, response, body) {
        expect(body).to.eql('OK with dynamic subdomains')
        done()
    })
})

No estás limitado a una URL aquí; puedes probar los subdominios especificados en la regexp.

Filtrado de Ruta

A veces pueden variar tus parámetros de URL. Por ejemplo, los parámetros de paginación no son estáticos. En ese caso, puedes utilizar las siguientes pruebas:

it('should support dynamic pagination', function(done) {
    nock('http://api.example.com')
        .filteringPath(/page=[^&]*/g, 'page=123')
        .get('/musics?page=123')
        .reply(200, 'Ok response with paginate')

    request('http://api.example.com/musics?page=13', function(error, response, body) {
        expect(body).to.eql('Ok response with paginate')
        done()
    })
})

Filtrado de Cuerpo de Peticiones

Si tienes campos diferentes en el cuerpo de la solicitud, puedes utilizar filteringRequestBody para eliminar diferentes campos como:

it('should create movie with dynamic title', function(done) {
    nock('http://api.example.com')
        .filteringRequestBody(function(path) {
            return 'test'
        })
        .post('/musics', 'test')
        .reply(201, 'OK');

    var options = {
        url: 'http://api.example.com/musics',
        method: 'POST',
        body: 'author=test_author&title=test'
    }

    request(options, function(err, response, body) {
        expect(body).to.eql('OK')
        done()
    })
})

Aquí author puede variar, pero puedes interceptar el cuerpo de la solicitud con title=test.

Igualación de Cabecera de Petición

En este cliente, un token es usado para autenticar al usuario cliente. Es necesario comprobar el encabezado para ver un token válido en el encabezado Authorization:

it('should match bearer token header', function(done) {
    nock('https://api.example.com')
        .matchHeader('Authorization', /Bearer.*/)
        .get('/musics')
        .reply(200, 'Ok response with music list')

    mediaClient.musicList(function(error, response) {
        expect(response).to.eql('Ok response with music list')
        done()
    })
})

Activar o Desactivar la Simulación

En casos de prueba, puedes habilitar peticiones HTTP reales estableciendo allowUnmocked como true. Veamos el siguiente caso:

it('should request performed to "http://api.example.com"', function(done) {
    var scope = nock('http://api.example.com', {allowUnmocked: true})
        .get('/musics')
        .reply(200, 'OK');
    http.get('http://api.example.com/musics'); // This will intercepted by the nock
    http.get('http://api.example.com/videos'); // This will make real request to service
})

En un escenario de nock, puedes ver un escenario para la URI /musics, pero también si realizas cualquier URL diferente de /musics, será una solicitud real a la dirección URL especificada en lugar de una prueba de falla.

Otras Utilidades

Hemos cubierto cómo escribir escenarios proporcionando una petición de muestra, respuesta, encabezado, etc., y comprobar el resultado real y esperado. También puedes utilizar algunas utilidades de expectativa como isDone(), limpiar el escenario de ámbito con cleanAll(), usar un escenario de nock para siempre usando persist() y listar simulaciones pendientes dentro de su caja de prueba mediante el uso de pendingMocks().

isDone()

Digamos que has escrito un escenario de nock y ejecutas una función real en un escenario de prueba. Dentro de tu caja de prueba, puedes comprobar si se ejecuta el escenario escrito o no como sigue:

it('should request performed to "http://api.example.com"', function(done) {
    var musicList = nock('http://api.example.com')
        .get('/musics')
        .reply(200, 'OK with music list');
    request('http://api.example.com/musics', function(error, response){
        expect(musicList.isDone()).to.eql(true)
        done()
    })
})

Dentro del callback de la solicitud, estamos esperando esa URL en el escenario de nock (http://api.example.com/musics) para ser llamado.

cleanAll()

Si utilizar un escenario de nock con persist(), estará para siempre disponible durante la ejecución de la prueba. Puedes despejar el escenario cuando lo desees mediante este comando como se muestra en el ejemplo siguiente:

it('should failed due to scope clearing', function(done) {
    var musicList = nock('http://api.example.com')
        .get('/musics')
        .reply(200, 'OK with music list');
    nock.cleanAll();
    request('http://api.example.com/musics', function(error, response, body){
        expect(body).not.eql('OK with music list')
        done()
    })
})

En esta prueba, nuestra petición y la respuesta coincide con el escenario. Sin embargo, después de nock.cleanAll() restablecemos el escenario, y no esperamos un resultado con 'OK with music list'.

persist()

Cada escenario de nock está disponible solamente la primera vez. Si quieres hacerla vivir para siempre, puedes utilizar una prueba como esta:

it('should be available for infinite request', function(done) {
    nock('http://api.example.com')
        .get('/musics')
        .reply(200, 'OK')
    // First call
    request('https://api.example.com/musics', function(error, response, body) {
        expect(body).to.eql('OK')
        done()
    })
    // Second call
    request('https://api.example.com/musics', function(error, response, body) {
        expect(body).to.eql('OK')
        done()
    })
    // .......
})

pendingMocks()

Puedes listar los escenarios nock pendientes que no se realizan aún dentro de la prueba como sigue:

it('should log pending mocks', function(done) {
    var scope = nock('http://api.example.com')
        .persist()
        .get('/')
        .reply(200, 'OK');
    if (!scope.isDone()) {
        console.error('Waiting mocks: %j', scope.pendingMocks());
    }
})

También puedes ver las acciones realizadas durante la ejecución de la prueba. Puedes llegar a hacer eso utilizando el siguiente ejemplo:

it('should log all the request', function(done) {
    var musicList = nock('http://api.example.com')
        .log(console.log)
        .get('/musics')
        .reply(200, 'OK with music list');
    request('http://api.example.com/musics', function(error, response, body){
        expect(body).eql('OK with music list')
        done()
    })
})

Esta prueba generará una salida como se muestra a continuación:

1	matching GET http://api.example.com:80/musics to GET http://api.example.com:80/musics: true

Consejos Rápidos

A veces, es necesario deshabilitar la simulación para direcciones URL específicas. Por ejemplo, puedes llamar al http://tutsplus.com real, en lugar del simulado. Puedes utilizar:

1	nock.nock.enableNetConnect('tutsplus.com');

Esto hará una solicitud real dentro de las pruebas. También, puedes globalmente activar/desactivar utilizando:

1	nock.enableNetConnect();
2	nock.disableNetConnect();

Ten en cuenta que si deshabilitas net connect e intentas acceder a una dirección URL no simulada, se obtendrá una excepción NetConnectNotAllowedError en tu prueba.

Conclusión

Es una buena práctica escribir las pruebas antes de tu aplicación real, aunque el servicio dependiente no esté implementado todavía. Más allá de esto, necesitas poder ejecutar las pruebas con éxito, cuando estés sin conexión. Nock te permite simular tu solicitud y respuesta para probar la aplicación.