Відмінності між даними, коли тоді (GWT) і Arrange Act Assert (AAA)?

У TDD є синтаксис Arrange Act Assert (AAA):

[Test]
public void Test_ReturnItemForRefund_ReturnsStockOfBlackSweatersAsTwo_WhenOneInStockAndOneIsReturned()
{
    //Arrange
    ShopStock shopStock = new ShopStock();
    Item blackSweater = new Item("ID: 25");
    shopStock.AddStock(blackSweater);
    int expectedResult = 2;
    Item blackSweaterToReturn = new Item("ID: 25");

    //Act
    shopStock.ReturnItemForRefund(blackSweaterToReturn);
    int actualResult = shopStock.GetStock("ID: 25");

    //Assert
    Assert.AreEqual(expectedResult, actualResult);
}

У тестах написання BDD використовується аналогічна структура, але з синтаксисом Given When When (GWT):

    [Given(@"a customer previously bought a black sweater from me")]
    public void GivenACustomerPreviouslyBoughtABlackSweaterFromMe()
    { /* Code goes here */   }

    [Given(@"I currently have three black sweaters left in stock")]
    public void GivenICurrentlyHaveThreeBlackSweatersLeftInStock()
    { /* Code goes here */   }

    [When(@"he returns the sweater for a refund")]
    public void WhenHeReturnsTheSweaterForARefund()
    { /* Code goes here */   }

    [Then(@"I should have four black sweaters in stock")]
    public void ThenIShouldHaveFourBlackSweatersInStock()
    { /* Code goes here */   }

Хоча їх часто вважають однаковими, є відмінності. Кілька основних:

1. GWT можна відобразити безпосередньо у специфікації файлу функцій у рамках BDD

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

3. Дано, коли і тоді є ключові слова в різних структурах BDD, такі як SpecFlow і Cucumber

Моє запитання: чи існують інші відмінності (крім назв) між AAA та GWT? І чи є якісь причини, крім зазначених вище, що одне слід віддати перевагу іншому?

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

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

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

• Вимога до рівня користувача: якщо склад має принаймні N предметів (запасів), коли користувач купує N предметів, то склад передає користувачеві N предметів
• Вимога до рівня системи 1: Враховуючи, що система інвентаризації містить N елементів (ив) в інвентарі, коли запит для N предметів вводиться в систему інвентаризації, тоді система інвентаризації зменшує кількість запасів для цього типу предметів
• Вимога до системного рівня 2: Зважаючи на те, що платіжна система має N елементів (товарів) в інвентарі, коли запит для N елементів (елементів) вводиться в платіжну систему, тоді платіжна система стягує користувача з N елементів (ив)
• ...
• Вимога рівня програміста 1: Дано 5 светрів, що знаходяться в інвентарі, коли 3 светри вилучаються з інвентарю, тоді в інвентарі залишаються 2 місць
• ...

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

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

public void Test_CaseWhereThereAreEnoughSweatersLeft() {
    // Arrange
    // setup Sweater Inventory mock (DB mocks, etc)
    // count = 5
    // when The number of sweaters remaining is request, return count
    // when Inventory is requested to remove N items, then count = count - N

    // Act
    // call the Unit Under Test to remove 3 items from inventory

    // Assert
    // the number of sweaters in the inventory is 2
    // the removal should return indicating a successful removal of items from the inventory
}

public void Test_CaseWhereThereAreNotEnoughSweatersLeft() {
    // Arrange
    // setup Sweater Inventory mock (DB mocks, etc)
    // count = 2
    // when The number of sweaters remaining is request, return count
    // when Inventory is requested to remove N items, then count = count - N

    // Act
    // call the Unit Under Test to remove 3 items from inventory

    // Assert
    // the number of sweaters remaining is still 2
    // the removal should return an error indicating not enough items in the inventory
}

Я думаю, це залежить від рамки, яку ви використовуєте. Як правило, наскільки я розумію, AAA підтримується рамкою NUnit, і, отже, це природний вибір у цьому плані. Що стосується теоретичних відмінностей між TDD та BDD, то вони здаються незначними. Дивіться це посилання, хтось більш кваліфікований, ніж я, щоб дати вам пояснення.

Різниці взагалі немає.
Три стани тесту:
Дано = Упорядкувати,
Коли = Акт,
Тоді = Ствердити.

Відмінність, яку ви вказали у питанні, полягає в відмінностях між TDD та BDD, а не GWT та AAA.

У TDD ви можете мати три різні методи для одного тесту

public class TestsOfFormatMethod
{        
    public void Arrange() { // set dependencies }
    public string Act() { // return formattted result }
    public string AssertThatFormatIsEmpty()
    {
        Arrange();
        var actual = Act();
        Assert.IsEmpty(actual);
    }
}