Сообщение Re: [React] Про первый блин из интеграционных тестов от 19.08.2019 17:03
Изменено 19.08.2019 17:04 VladCore
Re: [React] Про первый блин из интеграционных тестов
Здравствуйте, 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-ов, Сделал так на чистом
Получилось довольно локончино для первого раза. Здесь 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 из браузера в хроме себе локально для журнала.
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 из браузера в хроме себе локально для журнала.
Re: [React] Про первый блин из интеграционных тестов
Здравствуйте, 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-ов, Сделал так на чистом
Получилось довольно локончино для первого раза. Здесь BriefInfoArrived и MetricsArrived — глабальные переменные в react-приложении которые выставляется в true если биндинг не упал.
Что понравилось — работает и на билд сервере и локально.
Причем на билд сервере не надо ставить виртуальные X-ы для хрома.
Непонравилось — нельзя на 41м хроме тестить. Только на последнем стабильном. И самая старая версия протокола — 1.2 для 54го хрома. А хочется 41й. Хорошо хоть написали про это в доке.
А локально можно не прятать хром и видно как все работает при отладке.
Плюс скриншоты для разных разрешений и DPI автоматом хром умеет строить по API. Особенно круто когда логика от @media сильно зависит.
Плюс собираюсь подключить встроенный CPU и Memory Profiler что бы сразу видеть что именно тормозит на странице. Только вот с чего начинать хз
Пока не понял как логировать console из браузера в хроме себе локально для журнала.
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 из браузера в хроме себе локально для журнала.