2016-09-28 5 views
16

Mam następujące moduł próbuję przetestować żartem:Jak drwić importowane nazwie funkcji żartem, gdy moduł jest unmocked

// myModule.js 

export function otherFn() { 
    console.log('do something'); 
} 

export function testFn() { 
    otherFn(); 

    // do other things 
} 

Jak przedstawiono powyżej, eksportuje niektórych nazwanych funkcje i ważniejsze testFn wykorzystuje otherFn .

żartem kiedy piszę mój testów jednostkowych dla testFn chcę drwić funkcję otherFn bo nie chcę błędów otherFn mieć wpływ na moją testów jednostkowych dla testFn. Mój problem polega na tym, że nie jestem pewien, jak to zrobić:

// myModule.test.js 
jest.unmock('myModule'); 

import { testFn, otherFn } from 'myModule'; 

describe('test category',() => { 
    it('tests something about testFn',() => { 
    // I want to mock "otherFn" here but can't reassign 
    // a.k.a. can't do otherFn = jest.fn() 
    }); 
}); 

Każda pomoc/wgląd jest mile widziany.

+1

Nie chciałbym to zrobić . Kpiny z reguły nie są czymś, co i tak chcesz robić. A jeśli chcesz wyśmiać coś (z powodu nawiązywania połączeń z serwerem/etc.), Powinieneś po prostu wyodrębnić 'otherFn' w oddzielny moduł i wyśmiewać to. – kentcdodds

+0

Testuję również z użyciem tego samego podejścia do @jrubins. Testuj zachowanie 'funkcji A', która wywołuje' funkcję B', ale nie chcę wykonywać prawdziwej implementacji 'funkcji B', ponieważ chcę przetestować logikę zaimplementowaną w' funkcji A' – jplaza

+2

@kentcdodds, Czy mógłbyś wyjaśnić co masz na myśli, mówiąc: "Kpiny z reguły nie są czymś, co i tak chcesz robić"? Wydaje się to być dość szerokim (zbyt szerokim?) Stwierdzeniem, ponieważ kpiny z pewnością są czymś często używanym, prawdopodobnie z (przynajmniej niektórych) dobrych powodów. Może więc powołujesz się na to, dlaczego kpiny mogą nie być dobre, czy naprawdę masz na myśli w ogóle? –

Odpowiedz

7

Przefiltrowany kod nie pozwoli babel na pobranie powiązania, do którego odwołuje się otherFn(). Jeśli używasz funkcji expession, powinieneś być w stanie osiągnąć kpiny otherFn().

// myModule.js 
exports.otherFn =() => { 
    console.log('do something'); 
} 

exports.testFn =() => { 
    exports.otherFn(); 

    // do other things 
} 

 

// myModule.test.js 
import m from '../myModule'; 

m.otherFn = jest.fn(); 

Ale jak @kentcdodds wymienionych w poprzednim komentarzu, to prawdopodobnie nie będzie chciał drwić otherFn(). Zamiast tego po prostu napisz nową specyfikację dla otherFn() i wyśmiewaj wszelkie wymagane połączenia.

Tak na przykład, jeśli otherFn() jest złożenie żądania http ...

// myModule.js 
exports.otherFn =() => { 
    http.get('http://some-api.com', (res) => { 
    // handle stuff 
    }); 
}; 

Tutaj chciałbym mock http.get i aktualizować swoje twierdzenia w oparciu o szydzili wdrożeń.

// myModule.test.js 
jest.mock('http',() => ({ 
    get: jest.fn(() => { 
    console.log('test'); 
    }), 
})); 
+0

co jeśli inneFn i testFn są używane przez kilka innych modułów?czy powinieneś ustawić kodowanie http we wszystkich plikach testowych, które wykorzystują (jakkolwiek głęboki stos) te 2 moduły? Ponadto, jeśli masz już test na testFn, to dlaczego nie użyć kodu testFn bezpośrednio zamiast http w modułach używających testFn? – rickmed

7
import m from '../myModule'; 

nie działa na mnie, zrobiłem zastosowanie:

import * as m from '../myModule'; 

m.otherFn = jest.fn(); 
+0

W jaki sposób przywrócisz oryginalną funkcjonalność otherFn po teście, aby nie zakłócał innych testów? – Aequitas

0

udało mi się kpić nazwanego import takiego:

import { fn } from 'module'; 

jest.mock('module'); 

// when necessary, you can fake implementation like this 
// or else, it will just spy your function 
// fn.mockImplementation(() => { /* fake implementation */ }); 

describe('suite',() => { 
    test('unit',() => { 
     /* 
     * use case implementation 
     * 
     */ 

     expect(fn).toHaveBeenCalledTimes(1); 
    }); 
}); 
Powiązane problemy