Node/Jest. Testy wewnątrz funkcji asynchronicznej.

Question

Witam, przejdę od razu do konkretów. Mam aplikacje w Node/Express i chcę napisać testy automatyczne z użyciem Jest. Mój dylemat jest następujący:

const request = require('supertest');

// konfiguracja aplikacji dla trybu testowego
const dotenv = require('dotenv');
dotenv.config({ path: './config.test.env' });

const createApp = require('../server'); 

(async () => {
    // czekamy aż aplikacja się utworzy
    const app = await createApp();

    // uruchamiamy testy... 

    // przykładowy test, który będzie wymagał obiektu app do działania
    test('some test', () => {
        expect(2+2).toBe(4);
    });

})();

Gdyby wywołanie test() znajdowało się przed await createApp() to wszystko było by w porządku.

Jednak w mojej obecnej konfiguracji, dostaje przewidywalny komunikat:

Your test suite must contain at least one test.

Specjalnie się temu nie dziwie.

Zdałem sobie jednak sprawę, że nie mam pojęcia jak sprawić żeby Jest poczekał na wywołanie testu. Potrzebuje przecież wcześniej załadować aplikację, żeby później ją używać.

Szukałem informacji, ale nic nie udało mi się znaleźć.

Będę wyjątkowo wdzięczny za pomoc w tej sytuacji  Pozdrawiam serdecznie :)

Answer 1

Czemu nie załadujesz potrzebnych rzeczy w asynchronicznym handlerze beforeAll?

https://jestjs.io/docs/setup-teardown#one-time-setup

https://jestjs.io/docs/api#beforeallfn-timeout

Comments

Dziękuje za szybką pomoc! Z jakiegoś powodu nie pomyślałem o wykorzystaniu funkcji lifecycle w tej sytuacji.

---

@ScriptyChris,

Korzystając z okazji, pozwalam zadać sobie jeszcze drobne pytane w tym temacie. Mianowicie czy każde wywołanie handlera test powinno być niezależne, czy jednak mogą one być ze sobą powiązane? Np: czy ten kod jest dobrą praktyką:

beforeAll(async () => {
    app = await createApp();
    testSession = session(app);
});

// ----------------------------------------------------------------------------

test('should signin', async () => {
    const response = await testSession.post('/api/v1/auth/signin').send({...}).expect(200);
});

// ----------------------------------------------------------------------------

test('should not signin twice', async () => {
    await testSession.post('/api/v1/auth/signin').send({...}).expect(400);
});

// ----------------------------------------------------------------------------

test('should create new offer for auth user', async () => {
    await testSession.post('/api/v1/offers').send({...}).expect(201);
});

// ----------------------------------------------------------------------------

afterAll(async () => {
    await Offer.deleteMany();
});

 

Każde kolejne wywołanie test() zależy tu od poprzedniego. Oczywiście potem, testy będą bardziej zorganizowane i pogrupowane.

Dziękuje za radę :)

---

Ogólnie, testy jednostkowe - jak sama nazwa wskazuje - powinny testować jednostkę kodu i być od siebie niezależne. Więc abstrahując od użytego frameworka (chyba, że w docsach jest napisane inaczej), poszczególne testy powinny sprawdzać jeden przypadek. Jeśli chcesz sprawdzić, jak zachowuje się apka przy podwójnym logowaniu (tzn. jedno po drugim), to piszesz test, w którym logujesz się dwa razy.

Jeśli test A będzie zależny od testu B, to zmiana bądź np. wyłączenie testu B wpłynie na wynik testu A. Natomiast ,testy powinny działać przewidywalnie i powtarzalnie.

Przy okazji. powyższe wygląda bardziej na testy integracyjne niż jednostkowe, bo odpytujesz API. No chyba, że użyte metody post to mocki, które pod spodem nie komunikują się z API.

---

Przy okazji. powyższe wygląda bardziej na testy integracyjne niż jednostkowe, bo odpytujesz API. No chyba, że użyte metody post to mocki, które pod spodem nie komunikują się z API.

Znaczy wydaje mi się, że można to nazwać testami jednostkowymi, bo serwer nie musi być nawet uruchomiony by odpalić testy. Takie funkcjonalności jak korzystanie z ograniczonego 3rd party API uczynię oczywiście jako mocki. Chociaż ciężko mi się jeszcze wypowiedzieć w tej sprawie, bo pierwszy raz piszę testy automatyczne.

A to źle pisać testy integracyjne z Jest?

 

---

Możesz napisać testy integracyjne w Jest. Tylko myślałem, że to co piszesz uznajesz za testy jednostkowe.

W każdym razie, nie pisałbym testów zależnych od siebie, chyba że wykonujesz w nich kolejne kroki, np. w przypadku testu E2E:

1. zaloguj się
2. przejdź do ustawień profilu
3. zmień adres e-mail

Tutaj każdy kolejny test sprawdza jakiś osobny ficzer (logowanie, nawigacja, edycja danych), więc następny krok zależy od poprzedniego. Jednak, gdy piszesz test dla danego przypadku jednego ficzera, który np. ma sprawdzić, co się stanie gdy user będzie chciał zalogować się 2 razy, to powinieneś w tym jednym teście wywołać sytuację, w której takie logowanie następuje i sprawdzić czy dzieje się to, czego oczekujesz - niezależnie od tego co się dzieje w innych testach.

Co do testów jednostkowych, to polecam ten artykuł:

https://devstyle.pl/2020/06/25/mega-pigula-wiedzy-o-testach-jednostkowych/