ejemplos - varios controladores angularjs

AngularJS: ¿De qué sirve burlarse de los datos a través de $ httpBackend?

Question

Empecé a escribir mis primeras pruebas unitarias en AngularJS a través de Jasmine.

De alguna manera todavía no entiendo por qué debería burlarme de $ httpBackend. Para aclarar lo que aún no está claro, escribiré un pequeño ejemplo:

Imagine que tengo un servicio (myService) que obtiene datos de una URL:

 function getData() {
    return $http.get("http://example.com/data")
       .then(function (response) {
          return response.data;
        });
 }

Supongamos que una llamada GET a la URL " http://example.com/data " devuelve los siguientes datos:

{
    firstname: "John",
    lastname: "Doe"
}

La prueba correspondiente se vería así:

describe("Service: myService", function () {

    beforeEach(module("myApp"));

    var myService, $httpBackend;

    beforeEach(inject(function (_myService_, _$httpBackend_) {
        myService = _myService_;
        $httpBackend = _$httpBackend_;
    }));

    afterEach(function () {
        $httpBackend.verifyNoOutstandingExpectation();
        $httpBackend.verifyNoOutstandingRequest();
    });

    it("should get data", function() {
        var mockData = {datakey: "datavalue"};
        $httpBackend.whenGET("http://example.com/data").respond(mockData);

        var promise = myService.getData();
        $httpBackend.flush();

        promise.then(function(response){
            expect(response).toEqual(mockData)
        });
    })
});

A menos que esté equivocado, la prueba debería pasar, aunque los datos falsos no son iguales a los datos reales. La prueba siempre pasaría, sin importar cómo establezca los datos falsos, porque la función de servicio siempre se redirigiría a lo que está establecido en $ httpBackend.whenGET (" http://example.com/data ") .respond (mockData); .

Pensé que el propósito de tal prueba es verificar si los datos devueltos de una llamada GET [en este caso myService.getData () ] REALMENTE son los datos esperados y no algunos datos falsos aleatorios. Entonces, ¿cuál es el verdadero punto de burlarse de los datos en lugar de verificar si myService.getData devuelve los datos reales {firstname: "John", lastname: "Doe"} ?

Soy muy consciente de que también podría establecer los datos falsos en {firstname: "John", lastname: "Doe"} , pero cuando los datos reales de la URL sean dinámicos, los datos falsos y los datos reales no ser igual otra vez

¡Gracias de antemano!

Answer 1

Tienes que diferenciar de alguna manera entre:

• Pruebas unitarias
• Pruebas de integración
• Pruebas de extremo a extremo

Lo que quiere es probar la función getData (). Supongo que no le importa si los datos son correctos en este caso o no. Lo que quiere probar es si se llama a la URL correcta .

Entonces, se asegura de que esta unidad de su código funcione como se espera.

Toma este ejemplo:

var add = function(endpoint) {
  var sum = 0;
  endpoint().then(function(numberArray) {
    numberArray.forEach(number) {
      sum = sum + number;
    }
   });

   return sum;
}; 

Cuando te httpBackend del httpBackend aquí, en realidad no te importa si recuperas 1,2,3 o 5,6,7. Desea asegurarse de agregar el número que venga, agregarlos y devolverlos.

Su caso es mucho más simple, por lo que puede probar si la URL es correcta, y eso es todo.

Una prueba de extremo a extremo también incluiría un back-end adecuado y verifica si los datos están correctos.

La documentación de AngularJS lo deja en claro:

 it(''should fetch authentication token'', function() {
   $httpBackend.expectGET(''/auth.py'');
   var controller = createController();
   $httpBackend.flush();
 });

En este ejemplo, quiere asegurarse de estar llamando a la URL / punto final correcto. Si realmente obtienes el token correcto, es más apropiado realizar una prueba de integración o prueba de extremo a extremo, que luego llama al servidor real.