Тест підрозділу, NUnit або Visual studio?

Я використовую Visual studio (іноді resharper) для запуску мого тесту.

Я чув про NUnit, але не знаю багато речей про це ...

Чи варто мені це хвилювати? Чи може вона запропонувати щось краще, ніж візуальна студія?

Чи варто використовувати NUnit і чому?

NUnit має мало переваг перед MS-Test

1. Атрибут Suite - може агрегувати тести та виконувати їх окремо (корисно для великих проектів із швидкими та повільними тестами, наприклад)
2. Читальний метод звітування, наприклад, Assert.AreEqual(expected, actual)протиAssert.That(actual, Is.EqualTo(expected))
3. NUnit має часті оновлення версій - MS-Test має лише одну в VS-версії.
4. Багато інтегрованих бігунів, включаючи Resharper та TestDriven.NET
5. Очікуване твердження про виняток - може бути виконано за допомогою атрибута в NUnit, але повинно бути виконано за допомогою Try-Catch в MS-Test
6. [TestCase]! NUnit дозволяє проводити тестовані параметри.

З моєї нинішньої точки зору (після 8 місяців розробки в середньому близько 10 розробників) я б радив не використовувати MSTest з наступних причин

• Рамка сама по собі є досить повільною. Я не маю на увазі тестовий код, який ви пишете - це під вашим контролем. Я маю на увазі, що рамки, які виконують ці тести, повільні, будь то тестовий набір, одиничні тести тощо.
• Необхідність зберігати файл тестових метаданих, який завжди призводить до ускладнень, коли над ним працює декілька розробників (відтворення, наприклад, метаданих тощо). У кожному іншому тестовому наборі не потрібен файл метаданих. Організувати свої тести як би приємно, але ви можете досягти цього за допомогою просторів імен, класів та назв методів.
• Працюючи з постійною інтеграцією, якщо ви хочете запустити одиничні тести на своїй машині збирання, вам потрібно буде встановити Visual Studio на цій машині.

Іншими словами, якщо мені доведеться прийняти рішення ще 8 місяців тому, я б, мабуть, прийняв NUnit. Можливо, у мене немає інтегрованого звіту про результати тестування, але розробники матимуть більш легкий досвід тестування.

Ось мій досвід роботи з MS Test

• Ми проводимо MS Test з приблизно 3800 тесту.
• Тести потребують дуже багато часу, щоб почати виконувати те, що боляче при запуску одиничних тестів.
• Для проведення тестів потрібно близько 1 ГБ пам'яті. Ні, це не пов’язано з витоком пам'яті в наших тестах. Часто ми стикаємося з OutOfMemoryExceptions.
• Оскільки він використовує стільки ресурсів, ми починаємо виконувати тести з batch-файлів. То для чого корисна вся інтеграція?
• Це глючно і нестабільно:
  • Наприклад, якщо ви вилучите атрибут [Ignore] з тесту, він не розпізнає його, оскільки він десь кешує інформацію про тести. Вам потрібно оновити список тестів, який іноді вирішує проблему, або перезапустити VS.
  • Він випадковим чином не копіює довідкові збірки в каталог theout.
  • Елементи розгортання (додаткові файли, які слід використовувати) просто не працюють належним чином. Вони ігноруються випадковим чином.
• У файлах vsmdi та testrunconfig є прихована (не видно в тестовому коді) інформація. Якщо вас це не хвилює, це може не спрацювати.
• Функціонально це може бути порівняно з NUnit, але це дуже дорого, якщо ви вирішите використовувати VS тестер-видання.

Доповнення: Зараз у нас є ще кілька тестів, навіть не можна сказати, скільки. Більше неможливо запустити їх із Visual Studio, через OutOfMemoryExceptions та інших проблем нестабільності. Запускаємо тести зі скриптів. Результати тестів було б легко переглянути в Visual Studio, але коли рішення відкрите, VS виходить з ладу (кожен раз). Тому нам потрібно шукати невдалі тести за допомогою пошуку тексту. Переваги інтегрованого інструменту вже немає.

Ще одне оновлення : зараз ми використовуємо VS 2013. Багато чого змінилося. Вони переписали тестовий бігун MS Test втретє з моменту початку. Це спричинило багато змін, але жодна нова версія не зробила нічого кращого. Ми раді, що ми не використовували модні функції MS Test, оскільки всі вони вже не підтримуються. Це справді соромно. Ми все ще використовуємо скрипти для створення та запуску всіх тестів одиниць, оскільки це зручніше. Visual Studio потребував декількох хвилин для запуску тестів (вимірювання часу після компіляції до початку першого тесту). Вони, ймовірно, виправляють це оновленням, і це може бути специфічною проблемою нашого проекту. Однак Resharper набагато швидше під час виконання тих же тестів.

Висновок : принаймні в поєднанні з Resharper, MS Test корисний. І я сподіваюся, що вони нарешті дізнаються, як слід записати тестовий бігун, і не зроблять подібних змін, коли ми оновлюємо Visual Studio наступного разу.

NUnit можна використовувати в поєднанні з візуальною студією. Це рамка, а не окрема програма. Тож ви могли б подбати про те, чи підходить вам :).

alt text http://i3.codeplex.com/Project/Download/FileDownload.aspx?ProjectName=nunitit&DownloadId=61802

"Після установки плагіна ви знайдете нове підменю в меню інструментів."

Див. Http://nunitit.codeplex.com/ для отримання додаткової інформації про імпорт.

Також багато чого можна знайти, використовуючи пошук SO. У цій темі перелічено, наприклад, переваги NUnit перед стандартним тестуванням MS.

Найбільша перевага MS-тесту над NUnit - це тест MS, здатний генерувати макетні об’єкти за допомогою Reflection. Я вважав це дуже корисним

NUnit працює з Standard Edition VS.

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

NUnit - це блок тестування одиниць, який також підтримується resharper. Я думаю, ви використовуєте рамки тестування підрозділів Microsoft, тому NUnit є лише альтернативою продукту Microsoft;)

Ось посилання на головну сторінку NUnit: http://nunit.org

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

Якщо ви використовуєте Visual Studio, ви повинні використовувати NUnit для тестування одиниць, і якщо ви використовуєте java (Netbeans), ви повинні використовувати JUnit для тестування одиниць.

Ось приклад для простого тестування одиниць калькулятора

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using SimpleCalculator;
using NUnit.Framework;

namespace CalculatorTest
{
    [TestFixture]
    public class Class1
    {
        public Calculator _calculator;
        [TestFixtureSetUp]
        public void Initialize()
        {
            _calculator = new Calculator();
        }
        [Test]
        public void DivideTest()
        {
            int a = 10;
            int b = 2;
            int expectedValue = a / b;
            int actualvalue = _calculator.Divide(a, b);
            Assert.AreEqual(expectedValue, actualvalue,"Failure");

        }
    }
}