Модульное тестирование не является аналогом того, что вам нужно сделать. Это больше похоже на интеграционное тестирование или приемочное тестирование. Но это не относится к делу.
Ваша система предъявляет жесткие требования к проверке данных, поступающих в систему. Данные поступают в систему различными способами, и я предполагаю, что их необходимо проверять разными способами.
Рабочий процесс хорош для проектирования и управления бизнес-процессами (логикой), которые могут изменяться или требуют вмешательства человека. Это агностик, когда дело доходит до предмета проверки. Тем не менее, размещение вашего процесса проверки в качестве рабочего процесса может быть хорошей идеей, поскольку рабочие процессы разработаны так, чтобы быть гибкими, долгосрочными и способными к вмешательству человека. Размещение вашего процесса проверки в структуре конечного автомата рабочего процесса позволит вам определить стратегии проверки для различных типов импорта данных во время выполнения.
Вам необходимо спроектировать структуру проверки, которая в значительной степени полагается на композицию, а не на наследование для ее логики. Разбейте все различные способы, которыми данные могут быть импортированы в систему и проверены на атомарные этапы. Сгруппируйте эти шаги по ответственности и создайте интерфейсы с минимальными, наиболее минимальными свойствами и методами, необходимыми для реализации каждым из объектов реализации. Создайте базовые классы, которые состоят из этих различных интерфейсов. Из этой среды вы можете смешивать и сопоставлять реализации, которые соответствуют определенному этапу импорта или проверки.
И последнее. Рабочие процессы сериализуются в xaml для длительного хранения. Ваши классы также должны быть сериализуемыми xaml, чтобы переход от активности к репозиторию и обратно был как можно более плавным и простым.