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

Фактически Вы хотите повторно закодировать в тесте бизнес-логику, реализованную в тестируемом объекте, сделать тест и сущность связанными сильнее, чем сейчас, как результат - уменьшить ценность теста и увеличить трудоёмкость разработки за счёт количества случаев, когда изменения в компоненте приводят к необходимости изменений в тесте. Просто представьте себе, что у Вас есть код, есть набор тестов. Теперь вы меняете бизнес-логику: окно графика стало немодальным. Что будет в исходном случае? А всё хорошо, правильные тесты правильно работают, надо только добавить тест немодальности (или изменить тест модальности, если он был). Что будет в Вашей схеме? Правильно, надо будет бегать по уйме методов и переписывать условия "когда он доступен".

Правильный (с моей точки зрения) подход достигается следующим образом: если операция не может быть выполнена (скажем, пытаемся выполнить Click на недоступной кнопке) это приводит к генерации соответствующего исключения. Это автоматом реализует "недоступность" (точнее, правильный результат теста) для всех методов, прямо или косвенно вызывающих этот Click. Это автоматом отрабатывает ситуации типа "окно, которое должно было закрыться, не закрылось" и прочие возможные неприятности. Зачем это дублировать и портить?

ZyK_BotaNможет просто метод должен просто ничего не делать,
Какой именно метод? "Нажми на кнопку"? "Введи значение в ячейку"? Нее, такой метод должен работать совершенно однозначно. У него есть постусловие (кнопка нажата, значение введено в ячейку). Такой метод должен ничего не делать, если значение уже в ячейке. Но если окно недоступно - он должен кидать исключение. Без вариантов.

ZyK_BotaNзначит нужна прокся, которая может отфильтровать левые мессаги.
Зачем? Если цель - получить в результате тестирования красивую зелёную галочку, не надо писать никакой прокси, можно просто не писать тестов :)

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

На базовом уровне - api работы с интерфейсом, те самые методы "найди объект", "нажми кнопку", "выбери значение в комбобоксе" итп. В текущем проекте это обёртка над Selenium, до того была обёртка над SendInput, в целом не суть. На этом же уровне реализуются всякие фенечки, повышающие достоверность работы: значения в поля вводятся с небольшой паузой после каждого символа, метод "нажми кнопку" некоторое время ждёт её появления и/или становления доступной итп. Главное, что этот уровень позволяет формулировать тесты в виде наглядной, читаемой записи "действий пользователя", его задача - максимально отсечь прочий код от технической специфики. Он же отвечает за формирование хороших сообщений об ошибках.

Следующий уровень можно назвать настройкой на контекст. Для форм, фреймов и подобных конструктивных элементов описываются в виде функций составляющие их части. Например, у формы есть кнопка OK - значит, будет метод btnOk(), возвращающий эту кнопку в том виде, в котором её можно подать параметром в функцию click(). Если эта кнопка будет нажиматься часто, может быть реализован и метод clickOk(). Может появиться и более сложный типовой метод, скажем saveRecord(). Этим уровнем незачем слишком увлекаться, редкие вещи описывать не обязательно, его главная задача - дополнительно улучшить язык описания теста.

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

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

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