Действительно ли это - запах кода для одного метода для зависимости от другого?

Ну, контекста слишком мало, чтобы сказать, похоже, что _someDepend должен быть инициализирован в конструкторе.

Инициализация полей в Для меня метод экземпляра - большое НЕТ. Класс должен быть полностью готов к использованию (т. Е. Все методы работают) сразу после его создания; поэтому конструктор (ы) должен инициализировать все переменные экземпляра. См., Например, страницу о одношаговой конструкции в вики Уорда Каннингема.

Причина, по которой инициализация полей в методе экземпляра плохая, в основном состоит в том, что она накладывает неявный порядок на то, как вы можете вызывать методы. В вашем случае TheMethodIWantToTest будет делать разные вещи в зависимости от того, был ли DoStuff вызван первым. Обычно это не то, чего ожидают пользователи вашего класса, поэтому это плохо: - (.

Тем не менее, иногда такое связывание может быть неизбежным (например, если один метод получает ресурс, такой как дескриптор файла, и для его освобождения необходим другой метод). Но даже это должно быть выполнено в рамках одного метода, если возможно.

Трудно сказать, что относится к вашему случаю, без дополнительного контекста.

При условии, что вы не считаете изменяемые объекты запахом кода сами по себе, необходимость перевода объекта в состояние, необходимое для теста, является просто частью настройки для этого теста.

Лично я считаю, что одной из основных причин является проблема кроссплатформенности.

Программы Java, написанные «правильно» (без предположений о базовой операционной системе), могут работать на любой JVM. Это означает, что вы не привязаны к определенной платформе, в отличие от .NET, который связывает вас с Windows.

Я видел, как Java-код запускался на мэйнфреймах, маршрутизаторах Linux, внутри базы данных Oracle и, естественно, на ПК.

Большой запрет на то, чтобы это когда-либо происходило с недвижимостью. Свойства не должны никогда заботиться о том, в каком порядке они вызываются. Если у вас есть простое значение, которое действительно зависит от порядка методов, то это должен быть метод без параметров, а не метод получения свойства.

Да, думаю, в этом случае есть запах кода. Не из-за зависимостей между методами, а из-за неопределенной идентичности объекта. Вместо того, чтобы иметь Имитатор , который может находиться в разных состояниях персонажа, почему бы не иметь неизменную Персону ?

Если вам нужна другая Персона , просто создайте новый, а не изменение состояния существующего объекта. Если после этого вам нужно будет выполнить некоторую очистку, сделайте Persona одноразовым. Вы можете сохранить класс Impersonator в качестве фабрики:

using (var persona = impersonator.createPersona(...))
{
   // do something with the persona
}

Отвечая на заголовок: вызов методов друг друга (цепочка) неизбежен в объектно-ориентированном программировании, поэтому, на мой взгляд, нет ничего плохого в тестировании метода, который вызывает другой. В конце концов, модульный тест может быть классом, это «модуль», который вы тестируете.

Уровень цепочки зависит от дизайна вашего объекта - вы можете либо форк , либо каскад. .

• Разветвление: classToTest1.SomeDependency.DoSomething ()
• Каскадное : classToTest1.DoSomething () (который внутренне вызовет SomeDependency.DoSomething)

Но, как уже упоминали другие, определенно сохраните инициализацию вашего состояния в конструкторе, который, насколько я могу судить, вероятно, решит вашу проблему.