Тестовий приклад іменування найкращих практик [закрито]

Які найкращі практики називати одиничні тестові класи та методи тестування?

Про це йшлося раніше в розділі SO, на якій основі є популярні умови іменування для Unit Tests?

Я не знаю, чи це дуже хороший підхід, але в даний час у моїх тестових проектах я маю відображення один на один між кожним виробничим класом і тестовим класом, наприклад Product та ProductTest.

Тоді у своїх тестових класах у мене є методи із назвами методів, які я тестую, підкреслення, а потім ситуація та те, що я очікую, що відбудеться, наприклад Save_ShouldThrowExceptionWithNullName().

Мені подобається стратегія іменування Роя Ошерова , вона така:

[UnitOfWork_StateUnderTest_ExpectedBehavior]

У ньому є вся необхідна інформація про назву методу та структуровано.

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

Для складання я використовую типове .Testsзакінчення, яке, на мою думку, є досить розповсюдженим і однаковим для класів (закінчується на Tests):

[NameOfTheClassUnderTestTests]

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

Мені подобається дотримуватися стандарту іменування "Слід" для тестів , називаючи прилад для тестування після тестового блоку (тобто класу).

Для ілюстрації (використовуючи C # та NUnit):

[TestFixture]
public class BankAccountTests
{
  [Test]
  public void Should_Increase_Balance_When_Deposit_Is_Made()
  {
     var bankAccount = new BankAccount();
     bankAccount.Deposit(100);
     Assert.That(bankAccount.Balance, Is.EqualTo(100));
  }
}

Чому "Слід" ?

Я вважаю, що це змушує письменників-тестів назвати тест реченням у рядку "Чи повинен [бути в якомусь стані] [після / до / коли] [дія відбувається]"

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

Оновлення :

Я помітив, що Джиммі Богард також є шанувальником "слід" і навіть має тестову бібліотеку під назвою Should .

Оновлення (4 роки потому ...)

Для тих, хто цікавиться, мій підхід до іменування тестів змінювався роками. Одне з питань, пов’язаних із шаблоном Should, я описую вище, як його не просто зрозуміти з першого погляду, який метод перевіряється. Для OOP я думаю, що має сенс починати ім'я тесту з методу, який перевіряється. Для добре розробленого класу це повинно спричинити читабельні назви методів тестування. Зараз я використовую формат, подібний до <method>_Should<expected>_When<condition>. Очевидно, залежно від контексту, ви можете замінити дієслова Should / When на щось більш відповідне. Приклад: Deposit_ShouldIncreaseBalance_WhenGivenPositiveValue()

Мені подобається такий стиль називання:

OrdersShouldBeCreated();
OrdersWithNoProductsShouldFail();

і так далі. Це неправдиво дає зрозуміти, у чому проблема.

Кент Бек пропонує:

• Один тестовий прилад на «одиницю» (клас вашої програми). Тестові світильники - це самі заняття. Назва тестового кріплення має бути:

  [name of your 'unit']Tests
  

• Тести (методи випробування кріплення) мають такі назви:

  test[feature being tested]
  

Наприклад, маючи такий клас:

class Person {
    int calculateAge() { ... }

    // other methods and properties
}

Тестовим пристосуванням було б:

class PersonTests {

    testAgeCalculationWithNoBirthDate() { ... }

    // or

    testCalculateAge() { ... }
}

Назви класів . Щодо імен кріпильних тестів, я вважаю, що "Тест" досить поширений у всюдисущій мові багатьох доменів. Наприклад, в інженерній галузі: StressTestі в області косметики: SkinTest. Вибачте, що не погоджуюся з Кентом, але використання "Тесту" у моїх тестових пристосуваннях ( StressTestTest?) Заплутано.

"Unit" також багато використовується в доменах. Напр MeasurementUnit. Клас називається MeasurementUnitTestтестом "Measurement" або "MeasurementUnit"?

Тому я люблю використовувати префікс "Qa" для всіх моїх тестових класів. Наприклад QaSkinTestі QaMeasurementUnit. Його ніколи не плутають з об’єктами домену, а використання префікса, а не суфікса означає, що всі тестові прилади живуть разом візуально (корисно, якщо у вашому тестовому проекті є підробки або інші класи підтримки)

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

Назви методів тестування . Мені подобається називати свої методи WhenXXX_ExpectYYY. Це робить попередню умову зрозумілою та допомагає з автоматизованою документацією (a la TestDox). Це схоже на поради в тестовому блозі Google, але з більшим розділенням передумов та очікувань. Наприклад:

WhenDivisorIsNonZero_ExpectDivisionResult
WhenDivisorIsZero_ExpectError
WhenInventoryIsBelowOrderQty_ExpectBackOrder
WhenInventoryIsAboveOrderQty_ExpectReducedInventory

Я використовую концепцію Дано-Коли-Тоді . Погляньте на цю коротку статтю http://cakebaker.42dh.com/2009/05/28/given-when-then/ . У статті описано це поняття з точки зору BDD, але ви можете використовувати його і в TDD без будь-яких змін.

Дивіться: http://googletesting.blogspot.com/2007/02/tott-naming-unit-tests-responsrely.html

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

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

Нещодавно я придумав таку конвенцію щодо назви своїх тестів, їхніх класів та проектів, що містять проекти, щоб максимально покращити їх описові характеристики:

Скажімо, я тестую Settingsклас в проекті в MyApp.Serializationпросторі імен.

Спочатку я створять тестовий проект із MyApp.Serialization.Testsпростором імен.

В рамках цього проекту і, звичайно, простору імен, я створити клас, який називається IfSettings(зберігається як IfSettings.cs ).

Скажімо, я тестую SaveStrings()метод. -> Я назву тест CanSaveStrings().

Коли я запускаю цей тест, він покаже наступний заголовок:

MyApp.Serialization.Tests.IfSettings.CanSaveStrings

Я думаю, що це дуже добре говорить мені, що це тестування.

Звичайно корисно, що в англійській мові іменник "Тести" є таким самим, як і дієслово "тести".

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

Зазвичай назви тестів повинні починатися з дієслова.

Приклади включають:

• Виявляє (наприклад DetectsInvalidUserInput)
• Кидки (наприклад ThrowsOnNotFound)
• Буде (наприклад WillCloseTheDatabaseAfterTheTransaction)

тощо.

Інший варіант - використовувати "що" замість "якщо".

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

[ Редагувати ]

Після використання вищезгаданої конвенції про іменування вже трохи довше, я виявив, що префікс If може бути заплутаним при роботі з інтерфейсами. Так буває, що тестовий клас IfSerializer.cs виглядає дуже схожим на інтерфейс ISerializer.cs на " Вкладці відкритих файлів". Це може стати дуже дратівливим при переключенні між тестами, класом, що тестується, та його інтерфейсом. У результаті я б зараз вибрав префікс That over If як.

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

[Test] public void detects_invalid_User_Input()

Я вважаю, що це легше читати.

[ Завершити редагування ]

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

У VS + NUnit я зазвичай створюю папки в своєму проекті, щоб групувати функціональні тести разом. Потім я створюю класи тестових кріплень і називаю їх за типом функціональності, яку я тестую. Методи [Тест] названі в рядках Can_add_user_to_domain:

- MyUnitTestProject   
  + FTPServerTests <- Folder
   + UserManagerTests <- Test Fixture Class
     - Can_add_user_to_domain  <- Test methods
     - Can_delete_user_from_domain
     - Can_reset_password

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

Мені особисто подобаються найкращі практики, описані в "Посібнику з кишенькового JUnit" ... важко перемогти книгу, написану співавтором JUnit!

назва тестового випадку для класу Foo має бути FooTestCase або щось подібне (FooIntegrationTestCase або FooAcceptanceTestCase) - оскільки це тестовий випадок. Див. http://xunitpatterns.com/ щодо деяких стандартних угод про іменування, таких як тест, тестовий кейс, тестовий пристрій, метод тестування тощо.