Если вы хотите использовать это для модульного тестирования, попробуйте изменить свой подход к модульному тестированию. Если вы переходите к каждому частному методу, ваши тесты очень тесно связаны с реальной реализацией.
Распространенными проблемами при использовании этого подхода являются
- Очень хрупкие и трудные в обслуживании тесты
- Ваши тесты с большой вероятностью отражают поведение и код вашего приложения
- Существенное поведение ваших классов не очевидно из-за десятков тестов, описывающих каждую деталь
Каждый раз, когда вам необходимо выполнить рефакторинг некоторого кода, вам также придется менять несколько тестов. Это создаст огромный барьер для рефакторинга из-за времени и усилий, необходимых для исправления всех тестов на взлом. Вы даже рискуете создать нежелательное поведение, потому что вам нужно изменить столько тестов, чтобы изменить исходное поведение.
Я бы порекомендовал написать тесты, проверяющие поведение ваших классов. Если вы измените способ достижения этого поведения, вы вообще не будете ломать тесты и получите подтверждение, что ваш рефакторинг не изменил общее поведение.
Ваши тесты будут намного понятнее и будут определять действительно важные части вашего дизайна. Это помогает при рефакторинге или если кто-то (может быть, даже вы через несколько месяцев) должен снова войти в код.