Симуляции отсутсвия соединения с базой данных Oracle

iptables?

т.е. проще говоря, будут ли любые изменения в /etc/hosts мгновенно распространяться на всю систему?

Если нет, то какие существую альтернативные решения проблемы?

и изменения там будут мгновенны?

чем оно отличается от /etc/hosts/ ?

iptables или blackhole route

/etc/hosts не трогай

/etc/hosts не трогай

причины?

А что уже не модно какие-то mock библиотеки использовать для тестирования?

Как вариант, можно со стороны базы разрывать соединение.

А что уже не модно какие-то mock библиотеки использовать для тестирования?

ссылку сестра, ссылку!

и шоб оно мокало реальные данные и реальную нагрузку, да!

Как вариант, можно со стороны базы разрывать соединение.

а вот это как раз нельзя делать. База живая, на ней люди живут.

ссылку сестра, ссылку!
и шоб оно мокало реальные данные и реальную нагрузку, да!

Вам шашечки или поехали?

Если попробовать натравить ваш веб-сервис на локальную БД.

Как вариант, можно со стороны базы разрывать соединение.

а вот это как раз нельзя делать. База живая, на ней люди живут.

Ну так только «избранные» сессии обрывать, не всех же сразу.

1. надо перезапускать приложение, чтобы файл перечитался
2. надо восстанавливать файл после теста

ok

дропать конкретное tcp соединение можно с использованием conntrack

Если nf_conntrack_tcp_loose=0 то conntrack не будет подхватывать соединения без syn

В правилах iptables разрешить все пакеты относящихся к установленным соединениям и посылать RST на неустановленные соединения.

Дальше через «conntrack -D -p tcp -s ... --sport ...» в нужный момент удаляем конкретное соединение

iptables, лочишь исходящие - получаешь полный аутэж базы, лочишь входящие - получаешь таймаут на чтение. из теста не уверен, что сможешь нормально от рута выполнить, но это и не нужно: это интеграционные тесты того вида, который лучше оставить ручными

нельзя в современных приложениях удалять конкретное соединение. точнее можно, но бессмысленно: практически все (особенно оракловые) сервера имеют пул коннектов, в итоге ты протестируешь внутренний механизм подхватывания коннекта из пула, а не логику приложения по поводу обработки ошибок коннекта.

а, и еще конечно же - лочить на стороне базы те таблицы, в которые ты пишешь, чтобы получить таймаут на запись

мокать базу в интеграционном тесте на отказоустойчивость - это надо особенным мозгом обладать. грех такие мозги в IT насиловать, лучше сразу отдать для опытов

и шоб оно мокало реальные данные и реальную нагрузку, да!

Вам шашечки или поехали?

пионэр вам правильно говорит, что в его случае мок не подойдет, с ним он поедет в сторону, куда никакие разумные шашечки не повезут

Если попробовать натравить ваш веб-сервис на локальную БД.

локальный копия оракла для того, чтобы не использовать iptables - бухгалтерия оценит, чо

Ну так только «избранные» сессии обрывать, не всех же сразу

угу, и попутно расковырять все оракловые и серверные внутренние механизмы фейловера чтобы понять, сколько и каких соединений нужно обрывать. гениально.

это интеграционные тесты того вида, который лучше оставить ручными

ты так говоришь, как будто в shell скрипте нельзя выполнять построчно команду с помощью «Execute Selection». ОК?

можно, при чем не только в шелл-скрипте. но.

во-первых смысла в этом нет: таймауты в минуты (а для оракла учитывая фейловер на уровне севера - меньше смысла нет) сведут на нет все преимущества автоматизации.

во-вторых хорошая практика тестов на отказоустойчивость - выполнять их вручную для проверки того, что в околореальной ситуации все ветки сответствующего кода выполняются с теми же входными данными, что и юнит-тесты на эти ветки + выполнять их руками в рамках регрессионного-приемочного-системного тестирования.

в-третьих, если твое приложение и инфраструктура биде позволят из тестового фреймворка залочить базу на запись (а тут iptables'ами не обойдешься и проигнорить такой кейс нельзя) - проблемы у тебя гораздо глубже неавтоматизированных тестов. эту вещь должно быть возможно сделать только руками и только с умыслом.

поверь человеку со стажем тестирования на порядок больше твоего: это - тот кейс, когда автоматизировать всё - дорого, ненужно и в какой-то мере вредно

поверь человеку со стажем тестирования на порядок больше твоего: это - тот кейс, когда автоматизировать всё - дорого, ненужно и в какой-то мере вредно

ППКС. Однако тест кейсы должны быть задокументированы, да?

в виде шелл скрипта , в данном случае - это нормально?

всего лишь 3 -4 команды, которые нужно выполнять последовательно и вручную, анализируя вывод на консоль и документируя в самом же шелл скрипте входные параметры тест-кейса и быть может реакцию тестируемой системы на них.

Все что нужно в моем случае - это iptables и curl или его альтернатива, более приспособленная для тестирования Node.js сервисов

Применение GUI аналогов curl не нужно для этого, т.к. необходимо переключаться между множественными контекстами.

Все команды должны быть в одном месте.

ОК?

во-вторых хорошая практика тестов на отказоустойчивость - выполнять их вручную для проверки того, что в околореальной ситуации все ветки сответствующего кода выполняются с теми же входными данными, что и юнит-тесты на эти ветки + выполнять их руками в рамках регрессионного-приемочного-системного тестирования.

здесь, пожалуйста, поподробнее про связь юнит тестов с (интеграционным) тестированием на отказоустойчивость.

Как должны быть связаны входные данные для юнит тестов с остальными тестами?

выполнять их руками в ..

кого и как?

а и еще вопросик: где и как хранить тест кейсы (в виде шелл скриптов)?

имхается мне, что их нельзя вообще включать в гит репозиторий (и вообще они должны храниться не в папке проекта (что то типа test/integration/...), а в отдельной папке. Управление версиями не нужно.

Соответствующие версии шелл скрипта тупо копипастяться в Issue багтрекера (ну или как аттачмнет)

ОК?

ОК?

да не то чтобы очень

Однако тест кейсы должны быть задокументированы, да?

очевидно да

в виде шелл скрипта , в данном случае - это нормально?

всего лишь 3 -4 команды, которые нужно выполнять последовательно и вручную, анализируя вывод на консоль и документируя в самом же шелл скрипте входные параметры тест-кейса и быть может реакцию тестируемой системы на них.

а смысл? разные ДБ хосты - вот тебе и приходится прикручивать параметризованный запуск. вещи типа логирования, взвода тригера и логирования эвента в мониторинг - проверять нужно все равно руками, переключаясь от консоли с шелл-скриптом в другие окна. и какой профит от шелл скрипта кроме ухудшения человекочитаемости?

Применение GUI аналогов curl не нужно для этого, т.к. необходимо переключаться между множественными контекстами.

смотри выше. в любом случае нужно, или ты курлом собираешься смотреть заббикс?

Все команды должны быть в одном месте.

от авторов «автоматизировать надо все» и «лучше быть богатым и здоровым чем бедным и больным». напиши доку в вики, напиши тесткейсы в эксель или прости г-ди тестлинк, отдай их кому угодно, от тестировщика до админа или оставь себе: это нормальное решение для работы в команды, в отличие от шеллскрипта для ручного выполнения.

здесь, пожалуйста, поподробнее про связь юнит тестов с (интеграционным) тестированием на отказоустойчивость.

Как должны быть связаны входные данные для юнит тестов с остальными тестами?

а что непонятного: вот у тебя есть ветка, которая принимает на вход условный dbConnectionAlive = null (в глаза не видел ноду, но что там такое должно же быть). в рамках своего интеграционного теста и обрубаешь коннект описанными выше способами и дебагером смотришь, действительно у тебя там null, или на самом деле [«alive» => «false»]. то же с таймаутами - в нынешнем зоопарке фреймворков, где у системы таймаут один, у базы на другом конце другой, у сервера третий а у приложения четвертый - тебе нужно точно знать, что таймаут, который ты задал в тесте, соответствует требованиям и действительности. и так далее

кого и как?

ручные тесты, описанные в виде

1. Шаг - Результат

2. Шаг - Результат

в отличие от юнит-тестов, тут ты можешь не ограничиваться одним ассертом на тест, а в цепочку из 5 шагов написать 3 информационных результата и 2 ассерта, к примеру. в таких тестах это не то чтобы сильный моветон

а что непонятного: вот у тебя есть ветка, которая принимает на вход условный dbConnectionAlive = null..

т.е. имеются ввиду параметры, влияющие на логику выполнения программы?

имеются в виду параметры, которые ты в логику обработки исключений (в данном случае) передаешь юнит-тестом. собственно смысл юнит-тестов в этом случае - не проверить что исключение отловится - для этого делается первоначальный прогон и последующие периодические ручные проверки, а проверить то, что отловленное исключение корректно обрабатывается

wiki, testlink, googledoc - зависит только от того, как у вас в принципе организована документация. учитывая, что этих тестов не так много, а внутренняя вики есть практически везде - не вижу проблем сделать страницу «BolgenosAPI Fault tolerance testing» где все просто описать, даже не аттача скрипты - они же и так однострочные, впиши их в preformatted виде на страницу и все