Я впевнений, що більшість із вас пише багато автоматизованих тестів і що ви також натрапили на деякі загальні підводні камені під час тестування одиниць.
Моє запитання: чи дотримуєтесь ви будь-яких правил поведінки для написання тестів, щоб уникнути проблем у майбутньому? Якщо бути більш конкретним: які властивості хороших одиничних тестів або як ви пишете свої тести?
Мовні агностичні пропозиції заохочуються.
Відповіді:
Почніть з підключення джерел - Прагматичне тестування модулів на Java з JUnit (Є версія і з C # -Nunit .. але у мене є ця .. її агностик здебільшого. Рекомендується.)
Хороші тести повинні бути ПОЇЗДКОЮ (The acronymn НЕ липкі досить - у мене є роздруківка Cheatsheet в книзі , яку я повинен був витягнути , щоб переконатися , що я отримав це право ..)
Професіонал : у перспективі у вас буде стільки тестового коду, скільки у виробництві (якщо не більше), тому дотримуйтесь того самого стандарту гарного дизайну для вашого тестового коду. Добре обгрунтовані методи-класи з виявленням намірів імен, без дублювання, тести з хорошими іменами тощо.
Хороші тести також швидко проходять . будь-який тест, який займає більше півсекунди, повинен працювати. Чим довше для тесту потрібно тестовий набір .. тим рідше він буде виконуватися. Чим більше змін розробник спробує прокрастися між пробіжками .. якщо щось порушиться .. знадобиться більше часу, щоб з'ясувати, яка зміна стала винуватцем.
Оновлення 2010-08:
Крім них, більшість інших є рекомендаціями, які скорочують роботу з низькою вигодою: наприклад, "Не тестуйте код, яким ви не володієте" (наприклад, сторонні DLL-файли). Не займайтеся тестуванням геттерів та сетерів. Слідкуйте за співвідношенням витрат та вигод або ймовірністю дефектів.
Більшість відповідей тут, мабуть, стосуються загальної практики тестування одиниць взагалі (коли, де, чому і що), а не написання самих тестів (як). Оскільки питання здавалося досить специфічним щодо частини "як", я подумав, що опублікую це, взяте з презентації "коричневої сумки", яку я провів у своїй компанії.
1. Використовуйте довгі описові назви методів тестування.
- Map_DefaultConstructorShouldCreateEmptyGisMap()
- ShouldAlwaysDelegateXMLCorrectlyToTheCustomHandlers()
- Dog_Object_Should_Eat_Homework_Object_When_Hungry()
2. Напишіть свої тести у стилі « Упорядкувати / Діяти» .
3. Завжди надайте повідомлення про помилку зі своїми програмами.
Assert.That(x == 2 && y == 2, "An incorrect number of begin/end element
processing events was raised by the XElementSerializer");
4. Прокоментуйте причину тесту - яке ділове припущення?
/// A layer cannot be constructed with a null gisLayer, as every function
/// in the Layer class assumes that a valid gisLayer is present.
[Test]
public void ShouldNotAllowConstructionWithANullGisLayer()
{
}
5. Кожен тест повинен завжди повертати стан будь-якого ресурсу, який він торкається
Пам'ятайте про ці цілі (адаптовано з книги xUnit Test Patterns від Meszaros)
Деякі речі для полегшення цього:
Не забувайте, що ви можете робити тестування на інтеграцію і з вашою рамкою xUnit, але тримайте інтеграційні тести та одиничні тести окремо
Тести повинні бути ізольованими. Один тест не повинен залежати від іншого. Крім того, тест не повинен покладатися на зовнішні системи. Іншими словами, протестуйте свій код, а не код, від якого залежить ваш код. Ви можете протестувати ці взаємодії як частину ваших інтеграційних або функціональних тестів.
Деякі властивості чудових одиничних тестів:
Якщо тест не вдається, слід відразу зрозуміти, в чому проблема. Якщо вам доведеться використовувати налагоджувач для відстеження проблеми, то ваші тести недостатньо деталізовані. Тут допомагає рівно одне твердження за тест.
Коли ви рефактор, жоден тест не повинен провалюватися.
Тести повинні працювати так швидко, що ви ніколи не соромитесь їх виконувати.
Усі тести повинні проходити завжди; відсутність недетермінованих результатів.
Тести одиниць повинні бути добре враховані, як і ваш виробничий код.
@Alotor: Якщо ви пропонуєте, що бібліотека повинна мати лише тести одиниць у своєму зовнішньому API, я не згоден. Я хочу одиничні тести для кожного класу, включаючи класи, які я не піддаю зовнішнім абонентам. (Однак, якщо я відчуваю необхідність писати тести для приватних методів, тоді мені потрібно переробити. )
EDIT: Був коментар щодо дублювання, викликаного "одним твердженням на тест". Зокрема, якщо у вас є код для налаштування сценарію, а потім хочете зробити про нього кілька тверджень, але у вас є лише одне твердження за тест, ви можете дублювати налаштування через кілька тестів.
Я не приймаю такого підходу. Натомість я використовую тестові пристосування за сценарієм . Ось приблизний приклад:
[TestFixture]
public class StackTests
{
[TestFixture]
public class EmptyTests
{
Stack<int> _stack;
[TestSetup]
public void TestSetup()
{
_stack = new Stack<int>();
}
[TestMethod]
[ExpectedException (typeof(Exception))]
public void PopFails()
{
_stack.Pop();
}
[TestMethod]
public void IsEmpty()
{
Assert(_stack.IsEmpty());
}
}
[TestFixture]
public class PushedOneTests
{
Stack<int> _stack;
[TestSetup]
public void TestSetup()
{
_stack = new Stack<int>();
_stack.Push(7);
}
// Tests for one item on the stack...
}
}
Те, що ви хочете, - це визначення поведінки тестуваного класу.
Основний намір - підвищити вашу впевненість у поведінці класу.
Це особливо корисно при перегляді рефакторингу коду. У Мартіна Фаулера є цікава стаття щодо тестування на його веб-сайті.
HTH.
ура,
Роб
Тест спочатку повинен бути невдалим. Тоді ви повинні написати код, який змушує їх пройти, інакше ви ризикуєте написати тест, який помиляється і завжди проходить.
Мені подобається правильна абревіатура BICEP з вищезгаданої книги тестування прагматичних одиниць :
Особисто я відчуваю, що можна дістатися досить далеко, перевіривши, чи отримаєте правильні результати (1 + 1 повинен повернути 2 у функції додавання), спробувавши всі граничні умови, які ви можете придумати (наприклад, використовуючи два числа, сума яких є більшим за ціле максимальне значення у функції додавання) та вимушує умови помилок, такі як збої в мережі.
Хороші тести повинні бути ретельними.
Я не зовсім зрозумів, як це зробити у складних умовах.
Усі підручники починають видаватись без уваги, коли база вашого коду починає доходити до сотень 1000 чи мільйонів рядків коду.
Хороша архітектура може контролювати деякий вибух взаємодії, але неминуче, коли системи стають складнішими, автоматична система тестування зростає разом із нею.
Тут ви починаєте стикатися з компромісами:
Вам також потрібно вирішити:
де ви зберігаєте тестові приклади у своїй кодовій базі?
Я міг би продовжуватись назавжди, але моя думка полягає в тому, що:
Тести повинні бути ретельними.
Ці принципи я висвітлював ще в цій статті журналу MSDN яку, на мою думку, важливо прочитати будь-якому розробнику.
Я визначаю "хороші" одиничні тести, якщо вони мають такі три властивості:
Джей Філдс має багато корисних порад щодо написання одиничних тестів, і є посада, де він підсумовує найважливіші поради . Там ви прочитаєте, що слід критично замислюватися над своїм контекстом і судити, чи поради вам варті. Тут ви отримуєте безліч дивовижних відповідей, але саме ви вирішуєте, що найкраще підходить для вашого контексту. Спробуйте їх і просто переробляйте, якщо вам це погано пахне.
З повагою
Ніколи не вважайте, що тривіальний метод 2-х рядків спрацює. Написання швидкого тестового одиниці - це єдиний спосіб запобігти відсутності нульового тесту, неправильного знаку мінус та / або тонкої помилки оцінювання, неминуче, коли у вас ще менше часу для вирішення цього питання, ніж зараз.
Я другий відповідь "ДОПОМОГА", за винятком того, що тести ДОЛЖНІ покладатися один на одного !!!
Чому?
СУХА - Не повторюйтесь - стосується і тестування! Залежності тесту можуть допомогти 1) заощадити час налаштування, 2) заощадити ресурси кріплення та 3) визначити неполадки. Звичайно, тільки враховуючи, що ваша тестова основа підтримує першокласні залежності. Інакше, зізнаюся, вони погані.
Слідкуйте за http://www.iam.unibe.ch/~scg/Research/JExample/
Часто одиничні тести засновані на макетних даних або макетних даних. Мені подобається писати три типи одиничних тестів:
Сенс у тому, щоб уникнути повторного відтворення всього , щоб можна було протестувати всі функції.
Подумайте про два типи тестування та поводьтеся з ними по-різному - функціональне тестування та тестування продуктивності.
Використовуйте різні входи та показники для кожного. Можливо, вам доведеться використовувати різні програми для кожного типу тесту.
Я використовую послідовну конвенцію іменування тесту, описану стандартами імені Роя Ошерово, одиничні тестові позначення. Кожен метод у заданому класі тестового випадку має такий стиль іменування MethodUnderTest_Scenario_ExpectedResult.
Кожен розділ використовує верхній корпус верблюда і розмежований на нижчий бал.
Я вважаю це корисним під час запуску тесту, тест групується за назвою методу, який перевіряється. І конвенція дозволяє іншим розробникам зрозуміти наміри тесту.
Я також додаю параметри до назви методу, якщо досліджуваний метод був перевантажений.