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

Question

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

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

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

Я правильно понял?Существуют ли другие причины, по которым статические методы не подходят для тестирования?

Answer 1

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

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

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

Answer 2

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