Вот есть у меня тест из коробки (из create-react-app):
import React from 'react';
import ReactDOM from 'react-dom';
import { MemoryRouter } from 'react-router-dom';
import App from './App';
it('default route renders without crashing', () => {
const div1 = document.createElement('div');
ReactDOM.render(
<MemoryRouter>
<App />
</MemoryRouter>, div1);
});
он тестит только render и compomentDidMount дефолтого роутинга — он не падает.
дописал так:
for (let AnComponent of App.GetMenuComponents()) {
const name = AnComponent.displayName || AnComponent.name;
it(`RENDER {${name}}`, () => {
console.log(`---===*** Component: [${name}], type: [${typeof AnComponent}] ***===--- `);
const div2 = document.createElement('div');
ReactDOM.render(<MemoryRouter><AnComponent/></MemoryRouter>, div2);
});
}
стало лучше. тестируются тоже самое у всех компоненты, но череж одно место.
А как потестить обработку данных с web-api. Вот есть у меня живой WebAPI на
http://localhost:5678/ и я знаю какие он данные шлет.
Надо в тесте для
каждой заданной URL (одна урла на каждый роут)
1. дождаться пока загрузятся данные (данные приходят как из fetch в componentDidMount так и из WebSocket, который тоже создается в componentDidMount но сервер сначала тупит 0,5 секунды после создания соединенния и только потом отправляет, fetch понятно сразу получает ответ)
2. дождаться пока сработают "биндинги" полученных данных в приложении. Наверно это тоже самое что и 1, но если 1 упал то 2й не нужен.
3. захватить и вывести в консоль/лог все что в console
4. убедится что данные верные в DOM — это уже опционально.
5. А вот получить скриншот это я понимаю уже не все могут. Если что запустить headless хром не проблема.
В дальнейшем желательно как в Selenium возможность ввода данных в поля и нажатие кнопок. Но я хз зачем это лишнее.
Кто чем пользуется?
Вот тут их миллиард всяких:
https://docs.travis-ci.com/user/gui-and-headless-browsers/ 
Здравствуйте, VladCore, Вы писали:
VC>Вот есть у меня тест из коробки (из create-react-app):
VC>А как потестить обработку данных с web-api. Вот есть у меня живой WebAPI на http://localhost:5678/ и я знаю какие он данные шлет.
VC>Надо в тесте для каждой заданной URL (одна урла на каждый роут)
VC>1. дождаться пока загрузятся данные (данные приходят как из fetch в componentDidMount так и из WebSocket, который тоже создается в componentDidMount но сервер сначала тупит 0,5 секунды после создания соединенния и только потом отправляет, fetch понятно сразу получает ответ)
VC>2. дождаться пока сработают "биндинги" полученных данных в приложении. Наверно это тоже самое что и 1, но если 1 упал то 2й не нужен.
VC>3. захватить и вывести в консоль/лог все что в console
VC>4. убедится что данные верные в DOM — это уже опционально.
VC>5. А вот получить скриншот это я понимаю уже не все могут. Если что запустить headless хром не проблема.
VC>В дальнейшем желательно как в Selenium возможность ввода данных в поля и нажатие кнопок. Но я хз зачем это лишнее.
VC>Кто чем пользуется?
VC>Вот тут их миллиард всяких: https://docs.travis-ci.com/user/gui-and-headless-browsers/
Из за большого обилия framework-ов, Сделал так на чистом
const CDP = require('chrome-remote-interface');
Получилось довольно локончино для первого раза. Здесь BriefInfoArrived и MetricsArrived — глабальные переменные в react-приложении которые выставляется в true если биндинг не упал.
const myTest1 = async (context) => {
// проверяем что fetch приходит и РЕНДЕРИНГ не падает.
let isBriefInfoArrived = await context.waitForTrigger(5000,"BriefInfoArrived");
if (isBriefInfoArrived === false)
context.error("ERROR: BriefInfo was not bound in 8 seconds");
// после биндинга должны создасться DOM-елементы COMMON_INFO_HEADER_1, COMMON_INFO_HEADER_2, COMMON_INFO_HEADER_3, COMMON_INFO_HEADER_4
// если их нет то тест должен упасть
for(let footerHeaderIndex=1; footerHeaderIndex<=4; footerHeaderIndex++)
{
let id=`COMMON_INFO_HEADER_${footerHeaderIndex}`;
const headerValue = await context.getElementById(id);
if (headerValue === undefined)
context.error(`ERROR: Missed Header ${id}`);
else
console.log(`Header [${id}]: '${headerValue}'`);
}
// проверяем что по WebSocket-у приходят данные и все рендеры не падают при setState.
let areMetricsArrived = await context.waitForTrigger(5000,"MetricsArrived");
if (areMetricsArrived === false)
context.error("ERROR: Metrics were not bound in 5 seconds");
// тут недописано проверка что данные пришли корретные.
// в конце сохраняем скриншот
context.saveScreenshot(`bin/${context.pageSpec.fileName}.png`);
};
Что понравилось — работает и на билд сервере и локально.
Причем на билд сервере не надо ставить виртуальные X-ы для хрома.
Непонравилось — нельзя на 41м хроме тестить. Только на последнем стабильном. И самая старая версия протокола — 1.2 для 54го хрома. А хочется 41й. Хорошо хоть написали про это в доке.
А локально можно не прятать хром и видно как все работает при отладке.
Плюс скриншоты для разных разрешений и DPI автоматом хром умеет строить по API. Особенно круто когда логика от @media сильно зависит.
Плюс собираюсь подключить встроенный CPU и Memory Profiler что бы сразу видеть что именно тормозит на странице. Только вот с чего начинать хз
Пока не понял как логировать console из браузера в хроме себе локально для журнала.
Здравствуйте, VladCore, Вы писали:
Ибо я уже писал что там их ОЧЕНЬ много.
https://docs.travis-ci.com/user/gui-and-headless-browsers/
Но теперь я знаю что круче гугловского АПИ пока ничего для интеграционных тестов не придумали
Здравствуйте, VladCore, Вы писали:
VC>Здравствуйте, VladCore, Вы писали:
VC>Ибо я уже писал что там их ОЧЕНЬ много. https://docs.travis-ci.com/user/gui-and-headless-browsers/
вот к примеру puppeteer но он судя по ссылке ниже — ПОЛНЫЙ ШЛАК
https://medium.com/@e_mad_ehsan/getting-started-with-puppeteer-and-chrome-headless-for-web-scrapping-6bf5979dee3e
потому что Chrome DevTools протокол все равно нужно знать
Кто нить им или подобный пользуется?
