Всем привет.
TDD нам говорит, что все приватные методы класса должны тестироваться через его публичные контракты. И это вполне работает в том случае, если все возможные выводы класса можно получить используя достаточно простые к нему запросы (аля классические примеры из книг по TDD про "имя сотрудника" etc.).
Но когда речь заходит о классах, реализующих какой-нибудь сложный алгоритм, то возникает вот такая загвоздка:
С точки зрения инкапусляции и удобства для пользователя, весь magic, как правило, скрывается за методм с имене вроде process()/compute() etc. внутри которого уже вызывается конвейер из приватных методов, реализующих алгоритм.
В таком случае, если тестировать класс через его публичный контракт, то тест по сложности может не уступать самому алгоритму, а для проверки всех кейсов и превосходить его. Но, при этом, если бы тесты писались для отдельных частей алгоритма, то они, скорей всего, были бы довольно простыми.
И вот тут возникает вопрос: каким образом лучше всего организовать тестирование скрытой от пользователя функциональности класса?
з.ы. на ум приходит, конечно, мысль о разбиении класса на модули, но тогда у них появляются "жирные" интерфейсы, т.к. придется в интерфейсе передавать всю необходимую для вычислений информацию из основного класса. Ну либо в тесте наследоваться от тестируемого класса и явно вызывать приватные методы, что не является красивым решением.
з.з.ы чтобы было понятно о чем я говорю,
вот пример мной когда-то написанного класса с ужасным, с точки зрения тестирования, дизайном.
Средний
