Возможно, Вам подойдет baseline-тип test suite. Подробнее - в разделе  "Suite Modes and Baselines" http://blog.gurock.c...trail-4-0/2757/

Также, чтобы не быть "Дартаньяном" приведу пример точек зрения оппонентов такими, как вижу их я.

1. Возможно, я не до конца правильно понял цели и реализовал полезную идею, но не "в тему", а теперь отстаиваю ложные идеалы.

2. Возможно, другие дальше и больше видят цели и задачи, и, если реализовать "А", то потом можно достигнуть "В".

кстати, а с какой целью они были созданы?

Автотесты создаются по вполне конкретным целям: сокращение разворачивания подсистемы, приведения её в рабочий вид, бОльшее покрытие по данным, бОльшая частота тестирования и покрытие старой функциональности и т.д. На основании этих целей ставятся задачи: закодировать автоустановку и настройку, закодировать управление данными, ввести data driven в тесты, автозапуск тестов после коммита и т.д. Для меня "сверх задачи" - это именно те "украшательства", которые описаны в книге, советуемой Алексеем. Украшательства не двигают нас к цели, а отдаляют от неё, распыляя ресурсы. ИМХО, лучше мы "тут", пока потерпим, зато сделаем больше по основным задачам, которые никто не отменял.

Когда автоматизация приносит успехи (т.е. достигает хотя бы некоторых целей), то у менеджеров возникает желание "автоматизировать всё". Например: давайте теперь автоматизируем разворачивание "мегастенда", пусть отчёты будут гибкие и извивающиеся под каждого пользователя, пусть баги заводятся сами собой и пр. У меня возникает реакция "не трогайте мои идеальные тесты, они не были созданы для таких издевательств". Как реагировать на такие запросы? Возвращать к пересмотру основных целей и задач, аргументировать сроками по доработкам или можно выстроить грамотное планирование в самом начале?

1. Вы пишете "Но с помощью этого я могу осуществлять только проверку типов атрибутов объекта JSON, конкретно в этой схеме я проверяю boolean ли у атрибута isSuccess.", при этом в json schema проверяете ""type":"string"". Тип у Ваc boolean.

2. Вы можете проверять кол-во элементов и при помощи json schema. Более того, можно проверять и конкретные значения атрибутов.

Примеры тут: http://json-schema.org/example2.html

3. IMHO, тестирование api только через схему не достаточно, необходимо убедиться действительно ли сервер проделал ту работу, на которую ответил данным json. Тем не менее json schema весьма полезна не столько тестировщикам, сколько другим разработчикам при реализации данного api в своих приложениях. Думаю, они Вам за это еще не раз скажут спасибо.

Мне тоже интересен вопрос чем не подошла loadosophia?

Еще до её создания написал сравнение результатов на perl, сейчас переписал на python+matplotlib.

Если есть конкретные вопросы, могу попробовать подсказать конкретным кодом. До выкладывания в open source мой сугубо "под свои задачи" проект не подходит.