Должен ли я избегать статического метода, поскольку его трудно тестировать?

-3

Я прочитал книгу Working effectivly with Legacy code.Должен ли я избегать статического метода, поскольку его трудно тестировать?

Я понимаю технику разорвать зависимости в унаследованном коде

Но я хочу, чтобы понять, как избежать этих зависимостей в первый раз:

1- Что касается статических методов:

Я понимаю Introduce Instance Delegator

Но значит ли это, что мы должны избегать статических методов вообще?

(если это не просто Macro для некоторой части кода.

Значение это имеет некоторую реальную логику и это экземпляр независим?)

2- Глобальная переменная

Я понимаю Introduce Static Setter,

но снова - следует ли вообще избегать Singelton?

источник

2012-04-13 Elad Benda

Хотя я не совсем понимаю ваш вопрос, я бы ответил, чтобы этого не избежать. Почему вы считаете, что статические методы трудно тестировать? –

Если вы хотите работать с устаревшим кодом, его вообще не следует избегать, поэтому он называется ** устаревшим ** кодом ... Теперь я не самый большой фанатик C#, далеко от него. Но я бы не стал классифицировать C# как устаревший код (пока). –

@ Luis Filipe трудно издеваться над этими методами во время тестирования (как извлечение и переопределение) –

Критика статических методов в мире модульного тестирования традиционно является трудной издевательством над ними. Я никогда не соглашался с этим в качестве причины избегать статических методов (и в ожидании тех, кто не согласен, не у всех есть возможность использовать контейнер IOC).

Есть инструменты, которые будут издеваться над статическими классами, такими как JustMock.

Другим, более грязным подходом для насмешек синглонов является то, что singleton возвращает интерфейс и издевается над экземпляром на синглете во время модульного тестирования с использованием частного доступа или прямого отражения.

источник

2012-04-13 10:52:31 roken

Должен ли я избегать статического метода, поскольку его трудно тестировать?

ответ

Смежные вопросы