Як ви протестуєте приватні методи з NUnit?

Мені цікаво, як правильно користуватися NUnit. По-перше, я створив окремий тестовий проект, який використовує мій основний проект як орієнтир. Але в цьому випадку я не в змозі перевірити приватні методи. Я здогадувався, що мені потрібно включити свій тестовий код до мого основного коду ?! - Мабуть, це не правильний спосіб зробити це. (Мені не подобається ідея доставки коду з тестами.)

Як ви протестуєте приватні методи з NUnit?

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

Отже, NUnit не забезпечує жодного механізму тестування непублічних членів.

Хоча я погоджуюся, що в центрі уваги тестування одиниць повинен бути публічний інтерфейс, ви отримуєте набагато більш детальне враження про свій код, якщо ви також перевірите приватні методи. Рамка тестування MS дозволяє це зробити за допомогою використання PrivateObject і PrivateType, NUnit не робить цього. Що я роблю замість цього:

private MethodInfo GetMethod(string methodName)
{
    if (string.IsNullOrWhiteSpace(methodName))
        Assert.Fail("methodName cannot be null or whitespace");

    var method = this.objectUnderTest.GetType()
        .GetMethod(methodName, BindingFlags.NonPublic | BindingFlags.Instance);

    if (method == null)
        Assert.Fail(string.Format("{0} method not found", methodName));

    return method;
}

Цей спосіб означає, що вам не доведеться компромісувати інкапсуляцію на користь тестабельності. Майте на увазі, що вам потрібно змінити ваші BindingFlags, якщо ви хочете перевірити приватні статичні методи. Наведений вище приклад - лише для прикладних методів.

Загальна модель для написання одиничних тестів - це лише перевірка публічних методів.

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

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

Можливо, правильно перенести їх у клас помічників і оприлюднити їх там. Ваш клас може не піддаватися API.

Таким чином тестовий код ніколи не змішується з вашим відкритим кодом.

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

Можна перевірити приватні методи, оголосивши свою тестову збірку як дружню збірку цільової збірки, яку ви тестуєте. Детальніше дивіться за посиланням нижче:

http://msdn.microsoft.com/en-us/library/0tke9fxk.aspx

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

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

Якщо ви все ще відчуваєте необхідність перевірити внутрішню, то, можливо, ви також хочете розглянути глузування під час тестування, оскільки ви, як правило, хочете зосередитись на одному фрагменті коду. Знущання - це те, коли ти вводиш у нього залежність від об'єктів, але об'єкти, які вводяться, не є "реальними" або виробничими об'єктами. Це фіктивні об'єкти з жорстко кодованою поведінкою, щоб полегшити виділення поведінкових помилок. Rhino.Mocks - популярний фреймворк для вільних глузувань, який по суті буде писати об’єкти для вас. TypeMock.NET (комерційний продукт із доступною версією для спільноти) є більш потужною основою, яка може знущатися з об’єктів CLR. Дуже корисно для знущань із класів SqlConnection / SqlCommand і Datatable, наприклад, при тестуванні додатка бази даних.

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

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

Тестування одиниць еволюціонувало до тестової розробки. Можливість перевірити всі методи корисно для цієї програми.

Це питання є в минулі роки, але я думав, що поділюсь своїм способом цього.

В основному, у мене є всі мої тестові класи в збірці, яку вони тестують у просторі імен 'UnitTest' нижче 'за замовчуванням' для цієї збірки - кожен тестовий файл загортається у:

#if DEBUG

...test code...

#endif

блок, і все це означає, що а) він не поширюється у випуску і б) я можу використовувати internal/ Friendдекларації рівня без стрибків з обручем.

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

public partial class TheClassBeingTested
{
    private int TheMethodToBeTested() { return -1; }
}

в основних класах складання та тестовому класі:

#if DEBUG

using NUnit.Framework;

public partial class TheClassBeingTested
{
    internal int NUnit_TheMethodToBeTested()
    {
        return TheMethodToBeTested();
    }
}

[TestFixture]
public class ClassTests
{
    [Test]
    public void TestMethod()
    {
        var tc = new TheClassBeingTested();
        Assert.That(tc.NUnit_TheMethodToBeTested(), Is.EqualTo(-1));
    }
}

#endif

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

Основна мета одиничного тестування - тестування публічних методів класу. Ці публічні методи використовуватимуть ці приватні методи. Блок тестування перевірить поведінку того, що є загальнодоступним.

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

Для проекту, над яким я працюю лише над MSTest (на жаль), мабуть, існує спосіб, використовуючи аксесуари, для тестування приватних методів.

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

Ви просто не повинні перевіряти те, що не є загальнодоступним.

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

Якщо ваш клієнт може запустити тестовий набір і побачити, що наданий вами код насправді "працює", я не вважаю це проблемою (доки ви не віддасте свій IP-адресу через це). Що я включаю до кожного випуску - це тестові звіти та звіти про висвітлення коду.

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

Тож якщо ви дійсно хочете протестувати внутрішніх членів, можете скористатися одним із таких підходів:

1. Робіть свого члена публічним. У багатьох книгах автори пропонують такий підхід як простий
2. Ви можете зробити членів внутрішніми і додати InternalVisibleTo до assebly
3. Ви можете зробити учасників класу захищеними та успадкувати ваш тестовий клас від вашого класу, який перевіряється.

Приклад коду (псевдокод):

public class SomeClass
{
    protected int SomeMethod() {}
}
[TestFixture]
public class TestClass : SomeClass{

    protected void SomeMethod2() {}
    [Test]
    public void SomeMethodTest() { SomeMethod2(); }
}

Ви можете зробити свої методи захищеними внутрішніми, а потім використовуючи assembly: InternalsVisibleTo("NAMESPACE") тестовий простір імен.

Значить, НІ! Ви не можете отримати доступ до приватних методів, але це обхід.

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

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

Я хлопець на Java, і тому вигляд пакунків у C # можна назвати зовсім іншим. Досить сказати, що для доступу до цих методів два класи повинні знаходитися в одному просторі імен.