Методы конкретного экземпляра так же плохи, как и статические методы тестирования, не так ли?

Question

Метод If A() вызывает статический метод B(), это плохо, потому что они тесно связаны, верно?

Но если вместо того, чтобы звонить B(), A() вызывается нестатический метод C() для какого-то конкретного класса это было бы одинаково плохо для тестирования, верно?Потому что сейчас A() связан с конкретным классом, которому принадлежит C().

Единственный хороший сценарий возникает, когда используются интерфейсы (т.е. внедрение зависимостей), и A() вызывает метод интерфейса.

Правильно ли я все понял?Есть ли какие-либо другие причины, по которым статические методы плохи для тестирования?

Answer 1

Первый сценарий "плохой", потому что из-за него трудно обменять то, что B()вызывается.

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

Третий сценарий, как правило, является "лучшим", поскольку он позволяет вам легче изменить реализацию A(), но это верно только в том случае, если нет жестко запрограммированной конструкции конкретного класса, обеспечивающей A() (т.е.только в том случае, если внедрение зависимостей на самом деле использованный).

Answer 2

Это зависит от языка.Например, в таком языке, как Java, вызов метода экземпляра для конкретного класса совсем не плох для тестирования, потому что может быть сгенерирован прокси-экземпляр для этого конкретного класса, позволяющий эффективно перехватывать вызовы (и, как правило, имитировать их).Фактически, многие фреймворки используют этот прокси-сервер для внедрения своего собственного кода до / после пользовательского кода, чтобы обеспечить такие функции, как внедрение зависимостей и поддержка AOP.