Q-bart написав:FakiNyan написав:Q-bart написав:залежно від того фреймворк чи з нуля писали? Фреймворки мають якісь свої рішення з коробки, напр django - сам вміє створювати тестову БД, наповнювати їх даними і симулювати обробку http запитів.
Якщо ж нема, то:
1. можна замокати запити до БД, і симулювати різні кейси (це буде чисто юніт тестування) - http запитів не буде;
2. можна, створювати тестову БД якоюсь командою, типу `./main.js test` і піднімати http server і тоді іншим процесом копати його. Інтеграційні тести тоді вже. Чесно ніколи не бачив такого, швидше вже стейджинг
там, де я пишу, є можливість симулювати http запити без запуску самого серверу.
ну то файно, тоді має бути можливість створювати тестову БД, і мають бути якісь варіанти для наповнення цієї тестової бд даними:
1. fixtures - дані тримати в файликах напр, при створенні тестової бд читати їх і наповнювати БД;
2. при старті кожного тесту - створювати потрібні дані. Ну мали б бути бібіліотеки фабрики, щоб наповнювати дані автоматично (напр викликаєш User() і тобі автоматично додається запис в БД, з рандомними значеннями для цього юзера)
Наповнювати базу даних даними проблєм нема. Пишу на ноді, я ж жабаскриптер. Але от в якості бази даних використовую postgres.
Загалом, якшо це робити так, як ви кажете, то проблєм бути не має. Але я так розумію, що це трохи різні види тестування.
Якщо розробляти застосунки через створення тестів (test driven development), то ніби треба, аби тести запускались кожного разу, коли ми шось змінюємо в коді. Але якшо кожного разу треба буде створювати базу, наповнювати її, і тільки тоді запускати тести, то кожна найменша зміна коду займатиме достатньо часу, аби процес розробки був геть не файним.
Мабуть, є сенс розділяти тести на швидкі - юніт тести з замоканими даними, і довгі - котрі запускаються не під час розробки, а під час розгортання коду в розробницькому і виробничому середовищі.
Тобто, лише коли ми заливаємо код в певну гілку репозиторію - запускається процес автоматичного розгортання застосунку, в межах котрого створюватиметься тимчасова база даних, наповнюватиметься даними, а потім вже запускатимуться тести. При цьому ми можемо використовувати одні й ті ж самі тести, і в залежності від значень певних змінних середовища ці тести будуть або використовувати локальні замокані дані у вигляді якихось JSON файлів, або ж підключатись до бази даних, і використовувати дані вже з неї.
Тоді ще виникає питання, а шо ми тестуємо, якщо дані так і так будуть правильними, адже ми не будемо заносити в тимчасову базу даних неправильні дані? А ми будемо тестити саме SQL команди, бо в локальних тестах вони виконуватися не будуть, адже ми будемо просто мокати результат їх виконання.