Скорее всего будут проверять по тому же, что доступно в Vitals, потери кадров и ANR. Нет смысла проверять то, что разработчики не смогут диагностировать и исправить.
Я просто фантазирую. Если бы я решал такую задачу, я бы попробовал вариант с лежащим на дороге железным прутом и микрофоном регистрирующим воздействия. Какое оптоволокно? :) Очень занимательно узнать, что для такой, казалось бы, простой задачи решили использовать такие сложные технологии, вероятно это оправдано, но я, в силу отсутствия опыта, просто не могу увидеть причин.
Думаешь, что если написать все в одном классе, то у него будет меньше состояний и при этом код будет чище, менее связян и легок в поддержке? И при этом его еще будет легко протестировать?
Смысл тестирования сущностей отдельно друг от друга в том, что в тесте все сущности кроме тестируемой являются идеальной моделью себя самих. Тестируется то, как презентер взаимодействует с идеальным интерактором и наоборот.
TDD действительно не то, что должны делать тестировщики. Их задача писать функциональные тесты и, если хвататет квалификации, интеграционные. TDD не TDD, но разработчики испокон веков занимались тестированием, запуская свой код и проверяя как он работает, юнит-тестирование это скорее формализация этого процесса.
Смысл тестирования сущностей отдельно друг от друга в том, что в тесте все сущности кроме тестируемой являются идеальной моделью себя самих. Тестируется то, как презентер взаимодействует с идеальным интерактором и наоборот.