Odsłanianie wzorca modułu - testowanie jednostki za pomocą Jasmine

Question

Po krótkim romansie z odkrywczym wzorcem modułów doszedłem do wniosku, że mam do czynienia z cofnięciem, jeśli chodzi o moduły do ​​testowania jednostek. Nie mogę jednak zdecydować, czy to moje podejście do testowania modułu, czy też jest jakaś forma obejścia.

Rozważmy następujący kod:

var myWonderfulModule = (function() { 
    function publicMethodA (condition) { 
    if(condition === 'b') { 
     publicMethodB(); 
    } 
    } 

    function publicMethodB() { 
    // ... 
    } 

    return { 
    methodA : publicMethodA, 
    methodB : publicMethodB 
    } 
}()); 

Gdybym chciał przetestować (używając Jasmine) różne ścieżki prowadzące przez publicMethodA do publicMethodB. Mógłbym napisać mały test tak:

it("should make a call to publicMethodB when condition is 'b'", function() { 
    spyOn(myWonderfulModule , 'publicMethodB'); 
    myWonderfulModule.publicMethodA('b'); 
    expect(myWonderfulModule.publicMethodB).toHaveBeenCalled(); 
}); 

Jeśli dobrze rozumiem, jest to kopia publicMethodB wewnątrz zamknięcia, które nie mogą być zmieniane. Nawet jeśli zmienię myWonderfulModule.publicMethodB potem:

myWonderfulModule.publicMethodB = undefined; 

nazywając myWonderfulModule.publicMethodA będzie nadal prowadzony oryginalną wersję B.

Powyższy przykład jest oczywiście uproszczony, ale istnieje wiele scenariuszy mogę myśleć gdzie go byłby dogodny dla ścieżek warunkowych testu jednostkowego za pomocą metody.

Czy jest to ograniczenie ujawniającego wzoru modułu lub po prostu niewłaściwe użycie testu jednostkowego? Jeśli nie, to jakie są dostępne dla mnie obejścia? Zastanawiam się nad przejściem do czegoś takiego jak RequireJS lub powrotem do kodu niemodularnego.

Każda rada doceniona!

Answer 1

Nie można przetestować metod wewnętrznych zamknięcia. I nie powinieneś też tego szpiegować. Pomyśl o swoim module jako czarnej skrzynce. Włożyłeś coś i wyciągasz coś. Wszystko, co powinieneś przetestować, to to, czego oczekujesz od modułu.

Szpiegowanie metod w module nie ma większego sensu. Pomyśl o tym. Ty to śledzisz, test przechodzi. Teraz zmieniasz funkcjonalność, więc tworzy się błąd, test wciąż mija, ponieważ funkcja jest wciąż wywoływana, ale nigdy nie wspominasz o błędzie. Jeśli po prostu przetestujesz, że nie musisz szpiegować wewnętrznych metod, to dlatego, że są one nazywane implicite, gdy wynik modułu jest tym, czego oczekujesz.

W twoim przypadku nic się nie dzieje i nic nie wychodzi. To nie ma większego sensu, ale wierzę, że twój moduł współdziała z DOMem lub wykonuje wywołanie ajax. To są rzeczy, które możesz testować (DOM) lub powinieneś szpiegować (ajax).

Powinieneś również zapoznać się z Inversion of Control and Dependency Injection. Są to wzorce, które sprawią, że twoje moduły będą dużo łatwiejsze do przetestowania.

Answer 2

Jeśli użyjesz słowa kluczowego "this" podczas wywoływania publicMethodB() z publicMethodA() to zadziała. Na przykład:

var myWonderfulModule = (function() { 
    function publicMethodA (condition) { 
     if(condition === 'b') { 
      this.publicMethodB(); 
     } 
    } 

    function publicMethodB() { 
     // ... 
    } 

    return { 
     methodA : publicMethodA, 
     methodB : publicMethodB 
    } 
}());