Jak rozdzielić w jednym projekcie JavaScript funkcje z Mocha oraz z Jest?

0

Chciałbym naraz użyć w jednym projekcie frameworki Mocha oraz Jest. Przez jeden projekt rozumiem taki zestaw plików, że współdzielą plik package.json oraz katalog node_modules.

Niestety, wydaje się, że jest z tym problem. Załóżmy, że używam funkcji describe. Funkcja o takiej nazwie jest dostępna zarówno w Mocha, jak i w Jest. Niestety, jest ona w "globalnej przestrzeni nazw" (dobrze mówię? Tak to się nazywa w świecie JS?). Gdy najadę myszką na nazwę describe, Visual Studio Code pokazuje mi podpowiedź: var describe: Mocha.SuiteFunction. A chciałbym skorzystać na przykład w jednym pliku z funkcji Mocha o tej nazwie, a w drugim – z funkcji Jest o tej nazwie.

Jak rozróżnić funkcje Mocha oraz funkcje Jest?

Do tej pory znalazłem część rozwiązania: zauważyłem, że jest możliwe załadowanie modułu mocha (poprzez require("mocha")) i korzystanie z jego "przestrzeni nazw" (za pomocą mocha.describe itd.). Ale nie zauważyłem, by to było możliwe dla Jest.


UPDATE: Doszedłem do wniosku, że oryginalne pytanie jest bez sensu – bo przecież zarówno testy Jest, jak i testy Mocha uruchamiają się bez błędów. Kwestią pozostaje, jak umożliwić VS Code zobaczenie metod z Jest.

1

Dlaczego korzystasz z tych dwóch frameworków?

0

@Markuz: Zacząłem szukać informacji o frameworkach do testów jednostkowych w JavaScript. W internecie znalazłem strony opisujące wykorzystanie Mocha. W zasadzie chciałem wykorzystać na początku tylko ten framework, ale okazało się, że miałem problemy z włączeniem w nim wsparcia dla modułów ES6. Zacząłem więc szukać dalej i znalazłem Jest. Jednak również w nim miałem problemy z włączeniem wsparcia dla tych modułów. W międzyczasie znalazłem inne frameworki (pojedyncze wzmianki). Jednak nie chciałem szukać w nieskończoność; a, że dokumentacja tych dwóch oraz ich występowanie w internecie wydało się mi w porządku, to wybrałem je.


PS. Mogłem też zamienić Mocha na Jest. Jednak raz, że Mocha już miałem zainstalowane, dwa, że Jest i tak zdawał się nie dawać wsparcia modułów ES6, a trzy, że oceniłem, że dwa frameworki wyglądają lepiej niż jeden.

0

Założmy, że jesteś programistą który dołącza do nowego projektu, mamy 3 zespoły:
a) Używamy tylko Jest
b) Używamy tylko Mocha
c) Używamy Jest i Mocha, możesz sobie wybrać ale najlepiej naucz się dwóch bo część testów jest napisana w Jest a inne w Mocha

Który zespoł chciałbyś wybrać? ;)

Zawsze używałem Jest, wystarczył mi do przetestowania wszystkiego. Mocha chyba jest bardziej rozbudowaną alternatywą (czyli te funkcje co ma Jest + inne funkcje). Wybierz sobie jeden, 2 frameworki nigdy nie są lepsze od 1 (moim zdaniem, ale ja jestem leniwy i nie lubię czytać 2 dokumentacji, wolę 1).

Rozwiń też proszę "wsparcie modułów ES6", zarówno Jest jak i Mocha nie powinien mieć problemów z ES6.

0

To jest sensowne, co piszesz, ale pozwolę się nie zgodzić: są inne sytuacje, gdy dwa są lepsze niż jeden. Co prawda – może to moje lenistwo; może powinienem zrobić dwa projekty. Jeszcze nie wiem, na razie szukam rozwiązania.

Nie mogłem użyć modułów ES6 w Mocha oraz w Jest, ponieważ wyskakiwały mi jakieś błędy przy użyciu import ... from .... Nie wyskakują mi teraz, gdy zamieniłem to na require(). Jeśli chcesz dokładne komunikaty tych błędów, to OK, tylko trochę później, bo muszę pozmieniać część projektu, by znów korzystała z import/export.

0

Może inaczej - Twoim celem jest chęć nauki tych dwóch frameworków czy przetestowanie jakiejś funkcji w JS?

https://stackoverflow.com/questions/43366382/jest-es6-modules-unexpected-module-import
https://stackoverflow.com/questions/49656706/test-es6-modules-with-jest
taki błąd, tak?

Możesz użyć flagi "--experimental-modules" + wpis w package.json lub skorzystać z Babel.

0

To jest sensowne, co piszesz, ale pozwolę się nie zgodzić: są inne sytuacje, gdy dwa są lepsze niż jeden.

Ale to raczej nie jest ten przypadek, szczerze to wręcz przeciwnie.

Nie mogłem użyć modułów ES6 w Mocha oraz w Jest, ponieważ wyskakiwały mi jakieś błędy przy użyciu import ... from ....

Bo Jest nie obsługuje natywnie .mjs, potrzebuje do tego Babela (Mocha pewnie też, bo to nadal eksperymentalna funkcja), aby działało trzeba wykonać poniższe kroki:

  1. Zainstaluj Babela i potrzebne pluginy
npm i @babel/core @babel/preset-env babel-jest @types/jest -D
  1. Dotaj do package.json:
"jest": {
  "testMatch": [
    "**/?(*.)(spec|test).?(m)js"
  ],
  "moduleFileExtensions": [
    "js",
    "json",
    "mjs"
  ],
  "transform": {
    "^.+.mjs$": "babel-jest"
  }
},
"babel": {
  "presets": [
    [
      "@babel/preset-env",
      {
        "targets": {
          "node": "current"
        }
      }
    ]
  ]
},

Możesz zmodyfikować testMatch według potrzeb - pattern powyżej odpla testy dla wszystkich plików w projekcie z rozszerzeniami .test.js | .spec.js | .test.mjs | spec.mjs obojętnie gdzie się znajdują.

0

Doszedłem do wniosku, że oryginalne pytanie jest bez sensu – bo przecież zarówno testy Jest, jak i testy Mocha uruchamiają się bez błędów. Kwestią pozostaje, jak umożliwić VS Code zobaczenie metod z Jest.


@Markuz:

Powiedzmy, że moim aktualnym celem jest po prostu użycie tych dwóch frameworków razem. ;) Jeśli się nie da, zmienię ten cel.

Tak, tej flagi używałem w node wcześniej, zanim jeszcze zacząłem używać tych frameworków – i bez nich działało.

Obecnie pokazuje mi się Unexpected identifier ze wskazaniem na początek nazwy zmiennej występującej po wyrazie import.

@Maciej Cąderek, dzięki. Jednak na razie nie będę korzystać z Babela ani z innego podobnego, hm... kompilatora (?).

1 użytkowników online, w tym zalogowanych: 0, gości: 1