Чи є статична загально "зла" для тестування одиниць і якщо так, то чому рекомендує Решарпер? [зачинено]

Я виявив, що у C # .NET є лише 3 способи розділити тестові (макет / заглушки) залежності, які є статичними в C # .NET:

• Молі
• TypeMock
• JustMock

Зважаючи на те, що два з них не безкоштовні, а один не потрапив до версії 1.0, глузувати з статичних матеріалів не надто просто.

Це робить статичні методи та таке «зло» (у сенсі одиничного тестування)? І якщо так, то чому переосмислювач хоче зробити мені все, що може бути статичним, статичним? (Якщо припустити, що переосмислення не є також "злим".)

Уточнення: я говорю про сценарій, коли ви хочете одиничне тестування методу, і цей метод викликає статичний метод в іншому блоці / класі. У більшості визначень одиничного тестування, якщо ви просто дозволите досліджуваному методу викликати статичний метод в іншому блоці / класі, то ви не є одиничним тестуванням, ви інтегруєте тестування. (Корисний, але не одиничний тест.)

Дивлячись на інші відповіді тут, я думаю, що може виникнути певна плутанина між статичними методами, які зберігають статичний стан або викликають побічні ефекти (що мені здається дуже поганою ідеєю), і статичними методами, які просто повертають значення.

Статичні методи, які не мають стану та не викликають побічних ефектів, повинні бути легко перевірені. Насправді я вважаю такі методи функцією програмування «бідної людини»; ви передаєте методу об'єкт або значення, і він повертає об'єкт або значення. Більше нічого. Я не бачу, як такі методи взагалі негативно вплинуть на тестування одиниць.

Здається, ви плутаєте статичні дані та статичні методи . Якщо я добре пам’ятаю, Resharper рекомендує робити privateметоди в класі статичних, якщо їх можна зробити так - я вважаю, що це дає малу користь від продуктивності. Це НЕ рекомендується робити «все , що може бути» статичним!

У статичних методах немає нічого поганого, і їх легко перевірити (до тих пір, поки вони не змінюють статичних даних). Наприклад, подумайте про бібліотеку Maths, яка є хорошим кандидатом для статичного класу зі статичними методами. Якщо у вас є такий (надуманий) метод, як цей:

public static long Square(int x)
{
    return x * x;
}

то це виразно перевірено і не має побічних ефектів. Ви просто перевіряєте, що, коли проїдете, скажімо, 20, ви повернетесь 400. Без проблем.

Якщо справжнє питання тут "Як перевірити цей код?":

public class MyClass
{
   public void MethodToTest()
   {
       //... do something
       MyStaticClass.StaticMethod();
       //...more
   }
}

Потім просто перефактуруйте код і введіть, як зазвичай, виклик статичному класу на зразок цього:

public class MyClass
{
   private readonly IExecutor _externalExecutor;
   public MyClass(_IExecutor executor)
   {
       _exeternalExecutor = executor;
   }

   public void MethodToTest()
   {
       //... do something
       _exetrnalExecutor.DoWork();
       //...more
   }
}

public class MyStaticClassExecutor : IExecutor
{
    public void DoWork()
    {
        MyStaticClass.StaticMethod();
    }
}

Статистика не обов'язково зла, але вони можуть обмежувати ваші варіанти, коли справа стосується тестування одиниць підробками / макетами / заглушками.

Є два загальні підходи до глузування.

Перший (традиційний - впроваджений RhinoMocks, Moq, NMock2; в цьому таборі теж ручні макети та заглушки) покладається на тестові шви та введення залежності. Припустимо, ви перевіряєте одиничний статичний код, і він має залежності. У коді, розробленому таким чином, часто відбувається те, що статики створюють власні залежності, перетворюючи інверсію залежності . Незабаром ви виявите, що не можете вводити зграбні інтерфейси в тестований код, розроблений таким чином.

Другий (знущаються над чим - реалізовуються TypeMock, JustMock та Moles) спирається на API профілю .NET . Він може перехопити будь-яку з ваших інструкцій CIL і замінити шматок вашого коду підробкою. Це дозволяє TypeMock та іншим продуктам у цьому таборі глузувати з чого завгодно: статики, закритих класів, приватних методів - речей, не призначених для перевірки.

Триває дискусія між двома школами думки. Один з них говорить: дотримуйтесь принципів SOLID та проектуйте для встановлення достовірності (що часто включає просту статику). Інший каже: купуйте TypeMock і не хвилюйтесь.

Перевірте це: "Статичні методи - смерть для заповіту" . Короткий підсумок аргументу:

Для одиничного тестування потрібно взяти невеликий шматочок свого коду, перев'язати його залежності та перевірити його ізольовано. Зі статичними методами це важко не тільки у випадку, коли вони отримують доступ до глобального стану, але навіть якщо вони просто називають інші статичні методи.

Проста істина, яка рідко визнається, полягає в тому, що якщо клас містить залежність від компілятора, помітну від іншого класу, він не може бути перевірений ізольовано від цього класу. Ви можете підробити те, що схоже на тест, і з’явиться у звіті, ніби це тест.

Але він не матиме ключових визначальних властивостей тесту; невдача, коли все не так, проходження, коли вони правильні.

Це стосується будь-яких статичних викликів, викликів конструктора та будь-яких посилань на методи чи поля, не успадковані від базового класу чи інтерфейсу . Якщо ім'я класу з’являється в коді, це залежність від видимого компілятора, і ви не можете його перевірити. Будь-який менший шматок просто не є дійсною тестовою одиницею . Будь-яка спроба трактувати це так, ніби вона матиме результати, не більш значущі, ніж написання невеликої утиліти, щоб випромінювати XML, використаний вашою тестовою рамкою, щоб сказати "тест пройшов".

З огляду на це, є три варіанти:

1. визначити тестування одиниць для тестування одиниці, що складається з класу, і це твердо кодовані залежності. Це працює, забезпечуючи уникнення кругових залежностей.

2. ніколи не створюйте залежності часу компіляції між класами, за які ви відповідаєте за тестування. Це працює, якщо ви не заперечуєте проти отриманого стилю коду.

3. не використовуйте тест, а замість цього тест на інтеграцію. Що працює, за умови, що це не суперечить чомусь іншому, для чого потрібно використовувати термін інтеграційне тестування.

Про це немає двох шляхів. Пропозиції ReSharper та декілька корисних функцій C # використовуються не так часто, якби ви писали окремі тести атомних одиниць для всього свого коду.

Наприклад, якщо у вас є статичний метод і вам потрібно його заглушити, ви не можете, якщо не будете використовувати профіль ізоляції на основі профілю. Завдання, сумісне з викликом, - це змінити верхню частину методу для використання лямбда-позначення. Наприклад:

ПЕРЕД:

    public static DBConnection ConnectToDB( string dbName, string connectionInfo ) {
    }

ПІСЛЯ:

    public static Func<string, string, DBConnection> ConnectToDB (dbName, connectionInfo ) {
    };

Ці два сумісні з дзвінками. Клієнтів не потрібно змінювати. Тіло функції залишається колишнім.

Потім у вашому коді Unit-Test ви можете заглушити цей виклик так (припустимо, що це у класі, який називається База даних):

        Database.ConnectToDB = (dbName, connectionInfo) => { return null|whatever; }

Будьте обережні, щоб замінити його початковим значенням, коли закінчите. Це можна зробити через спробу / нарешті, або, у вашому прийомі тестування блоку, того, що викликається після кожного тесту, написати такий код, як цей:

    [TestCleanup]
    public void Cleanup()
    {
        typeof(Database).TypeInitializer.Invoke(null, null);
    }

який повторно викликатиме статичний ініціалізатор вашого класу.

Функції Lambda не настільки багаті на підтримку, як звичайні статичні методи, тому такий підхід має такі небажані побічні ефекти:

1. Якщо статичний метод був методом розширення, вам слід спершу змінити його на нерозширений метод. Resharper може зробити це за вас автоматично.
2. Якщо будь-який із типів даних статичних методів є збіркою з вбудованим інтеропом, наприклад, для Office, вам доведеться обернути метод, обернути тип або змінити його на тип "об'єкт".
3. Ви більше не можете використовувати інструмент рефакторингу змін підпису Resharper.

Але скажімо, що ви взагалі уникаєте статики, і перетворите це в метод екземпляра. Це все ще не піддається вибору, якщо метод не є віртуальним чи реалізованим як частина інтерфейсу.

Тож насправді кожен, хто пропонує виправити затруднення статичних методів, - це зробити їх екземплярами методів, вони також будуть проти методів екземплярів, які не є віртуальними або не є частиною інтерфейсу.

То чому C # має статичні методи? Чому це дозволяє використовувати невіртуальні методи екземпляра?

Якщо ви використовуєте будь-яку з цих "функцій", ви просто не можете створити окремі методи.

То коли ви їх використовуєте?

Використовуйте їх для будь-якого коду, який ви не очікуєте, що хтось коли-небудь захоче заглушити. Деякі приклади: метод Format () класу String, метод WriteLine () класу Console, метод Cosh () класу Math

І ще одне .. Більшість людей не переймається цим питанням, але якщо ви можете виконати непрямий дзвінок, це ще одна причина уникати методів екземплярів. Бувають випадки, коли це хіт виступу. Ось чому в першу чергу існують невіртуальні методи.

1. Я вважаю, що це частково тому, що статичні методи "швидше" викликати, ніж методи екземпляра. (У лапках, бо пахне мікрооптимізацією) див. Http://dotnetperls.com/static-method
2. Це говорить вам, що йому не потрібен стан, тому його можна викликати з будь-якого місця, видаляючи накладні витрати, якщо це єдине, що комусь потрібно.
3. Якщо я хочу знущатися над цим, то я думаю, що це правило, що це оголошено в інтерфейсі.
4. Якщо це оголошено в інтерфейсі, R # не запропонує вам зробити його статичним.
5. Якщо це оголошено віртуальним, то і R # не запропонує вам зробити його статичним.
6. Статичне утримання стану (полів) - це те, що завжди слід уважно розглядати . Статичний стан і нитки змішуються, як літій і вода.

R # - не єдиний інструмент, який зробить цю пропозицію. Аналіз коду FxCop / MS також зробить те саме.

Я б загалом сказав, що якщо метод є статичним, він, як правило, повинен бути перевіреним. Це приносить певний розгляд дизайну та, ймовірно, більше обговорень, ніж у мене зараз у пальцях, тому терпляче чекаю прихильників голосів та коментарів ...;)

Я бачу, що через довгий час ніхто ще не констатував дійсно простий факт. Якщо переробник скаже мені, що я можу зробити метод статичним, це означає для мене величезну річ, я чую його голос, який говорить мені: "Ей, ти, ці логіки не є ВІДПОВІДАЛЬНІСТЮ поточного класу, з якою слід обробляти, тому він повинен залишатися поза в якомусь класі помічників чи щось таке ".

Якщо статичний метод викликається всередині іншого методу , запобігти або замінити такий виклик неможливо. Це означає, що ці два методи складають єдину одиницю; Одиничний тест будь-якого виду тестує їх обох.

І якщо цей статичний метод спілкується з Інтернетом, з'єднує бази даних, показує графічні інтерфейси GUI або іншим чином перетворює тест Unit в повний безлад, він просто обходиться без легкої роботи. Метод, який викликає такий статичний метод, не піддається тестуванню без рефакторингу, навіть якщо він має безліч чисто обчислювального коду, який би дуже виграв від тестування одиниці.

Я вважаю, що Resharper дає вам впевненість і застосовує правила кодування, з якими він був налаштований. Коли я використав Resharper, і він сказав мені, що метод повинен бути статичним, він повинен бути приватним методом, який не діє на жодні змінні екземпляри.

Що ж стосується testablity, то цей сценарій не повинен бути проблемою, оскільки ви не повинні тестувати приватні методи в будь-якому випадку.

Що стосується перевірки статичних методів, які є загальнодоступними, то одиничне тестування стає важким, коли статичні методи торкаються статичного стану. Особисто я би звів це до мінімуму і максимально використовував статичні методи як найчистіші функції, коли будь-які залежності передаються методу, яким можна керувати тестовим кріпленням. Однак це дизайнерське рішення.