Если классы A и B ожидают определенного поведения от классов, с которыми сотрудничают, то вам следует проверить, чтобы такое поведение происходило.Если вы хотите избежать огромного шарика грязи, к которому вы стремитесь, проводя звонки из А в В в С, то вам следует применить Голливудский принцип / DIP, чтобы разорвать эту зависимость.A должен зависеть от IB (интерфейс B), а не от экземпляра B. Тогда тесты A могут просто утверждать, что A делает то, что должен, включая правильные действия перед лицом исключений, выдаваемых IB (или игнорируя их),Аналогично, B может зависеть от интерфейса C, IC, и тесты B могут аналогичным образом игнорировать детали того, что C может или не может делать, вместо этого сосредоточив внимание только на том, что делает B.
Интеграционный тест, проводящийвверх от A до B к C сможет проверить, что классы взаимодействуют правильно, а также будет местом, где исключение, которое возникает в C, всплывает от A, если это именно то, что вы хотите, чтобы произошло.И если позже окажется, что C просто возвращает null, а не вызывает исключение, тогда ваш интеграционный тест не пройден, и вы увидите, что произошло новое поведение.Однако я бы не стал загромождать свои отдельные модульные тесты тестами, показывающими, что если что-то сломается, исключение будет пузыриться, поскольку это поведение по умолчанию.Вместо этого я мог бы проверить, что любые новые исключения, которые я поднимаю, генерируются, когда ожидается, и что любая обработка исключений, которые я выполняю, работает так, как я ожидаю.Это потому, что в модульном тестировании вы должны тестировать только тестируемый код, а не поведение соавторов.