Ещё для Jenkins есть плагин. Но тогда поднимать jenkins придется. То на то

У Вас по-моему нет хорошего представления о графах и структурах данных. Графы в теории графов это НЕ структуры "если А то Б". Это построения, а не алгоритмы.

Нет графов для "будет ли это поле вообще и если это дропдаун то какие в нем будут опции".

Если Вы не напишете этих правил сами, никто их за Вас не напишет, и никакой специальной базы данных под это нет.

База данных она на то и база данных что база, а не генератор путей и проверка связей. Ну, допустим, пути по этим данным генерировать ещё можно, но на проверки дропдаунов это не рассчитано.

В теории думаю что можно это закодить -- элементы как объекты и правила в них, а по этим правилам проверять что "для этого элемента вызываемый им объект когда-то появился", а "для этого элемента были выполнены все предусловия".

Написать что-то что будет перебирать путями прохождения тоже можно {хотя вопрос как это оптимизировать}.

Но это своя работа -- нет таких графов.

https://ru.wikipedia.org/wiki/Граф_(математика)

Ну так а если не гоафовая база подойдёт для описания этого так что?

Что ты хочешь сделать, в чем хочешь выиграть и в чем не хочешь проиграть?

Как структура хранилища тестовых данных поможет тебе в случае тест дизайна всех сочетаний?

В том что это нужная мне структура ?

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

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

В резюме ж

Я думаю прикол в том, что иерархичность тестовых данных никак не поможет тебе делать более простой тест дизайн. Скорее наоборот, ты сначала делаешь тест дизайн своих Пейдж объектов и их публичных методов (что как раз опишет все взаимодействия в UI и будет являть собой граф вызовов функций с разными параметрами) , и уже потом на каждом конкретном методе у тебя будет какой-то входной аргумент, которому можно/нужно  быть параметризованным

Я работал с neo4j, теперь могу гордиться до скорой пенсии, считаю.

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

У нас есть neo4j на соседнем проекте, могу там конкретные вопросы позадавать, если надо )

Как-то так, да, согласен с Олегом. Но почитать книгу про базы всегда можно и полезно. Может быть кто-нибудь скинет ссылку на покупку хорошей книги / бесплатный ресурс на этот счёт, Алекс почитает и отпишется помогло ли ему

Графовые базы вообще где применяют?

Насколько для тестировщика полезная информация и шанс нарватся на такое в реальной жизни? А то может тоже книжку прочитать умную О_о

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

Оу! Ответ был на поверхности. Спасибо )

Ну как бы все говорят что зачем но никто не может сказать как это по другому сделать