Написання мінімального коду для проходження одиничного тесту - без обману!

Коли ви робите TDD і пишете тестовий блок, як протистояти бажанням "обдурити" під час написання першої ітерації коду "впровадження", який ви тестуєте?

Наприклад:
Давайте мені потрібно обчислити Фактор числа. Я починаю з одиничного тестування (використовуючи MSTest) приблизно так:

[TestClass]
public class CalculateFactorialTests
{
    [TestMethod]
    public void CalculateFactorial_5_input_returns_120()
    {
        // Arrange
        var myMath = new MyMath();
        // Act
        long output = myMath.CalculateFactorial(5);
        // Assert
        Assert.AreEqual(120, output);
    }
}

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

Справа в тому, що я постійно спокушаюся написати наступне:

public class MyMath
{
    public long CalculateFactorial(long input)
    {
        return 120;
    }
}

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

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

Це ідеально законно. Червоний, зелений, Refactor.

Перший тест проходить.

Додайте другий тест, з новим входом.

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

Третя частина Червоного, Зеленого, Рефактора є найважливішою. Refactor для видалення дублювання . Зараз у вас буде дублювання коду. Два заяви, що повертають цілі числа. І єдиний спосіб видалити це дублювання - це правильно кодувати функцію.

Я не кажу, що не пишу це правильно з першого разу. Я просто кажу, що це не обман, якщо ви цього не зробите.

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

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

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

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

Дядько Боб Мартін говорить так:

Якщо ви не займаєтеся розробкою тестових програм, назвати себе професіоналом дуже важко. Джим Коплін покликав мене на килим для цього. Йому не сподобалось, що я це сказав. Насправді, його позиція зараз полягає в тому, що Test Driven Development знищує архітектури, оскільки люди пишуть тести на відмову від будь-якого іншого виду думок і розривають їх архітектури в шаленому поспіху, щоб отримати тести, і він отримав цікавий момент, це цікавий спосіб зловживати ритуалом і втратити наміри, що стоять за дисципліною.

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

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

Дуже гарне запитання ... і я повинен не погодитися майже з усіма, крім @Robert.

Написання

return 120;

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

Ось чому:

• Обчислити Фактор - це особливість, а не "повернути константу". "повернення 120" не є розрахунком.

• аргументи «рефактора» неправильно керуються; якщо у вас є два випадки випробування для 5 і 6, цей код все ще не так, тому що ви не обчислення факторіала на все :

  if (input == 5) { return 120; } //input=5 case
  else { return 720; }   //input=6 case
  

• якщо ми дотримуємось аргументу «рефактор» буквально , тоді, коли у нас є 5 тестових випадків, ми б викликали YAGNI та реалізували функцію за допомогою таблиці пошуку:

  if (factorialDictionary.Contains(input)) {
      return factorialDictionary[input]; 
  }
  throw new Exception("Input failure");
  

Жоден з них не на самому ділі обчислень нічого, ви . І це не завдання!

Коли ви написали лише один одиничний тест, однорядкова реалізація ( return 120;) є законною. Написати цикл, що обчислює значення 120 - це було б обманом!

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

Основне правило, яке може бути тут корисним: нуль, один, багато, партій . Нуль і один - важливі крайові випадки для факторіалу. Вони можуть бути реалізовані однолінійними. Тестовий випадок "багато" (наприклад, 5!) Змусив би вас написати цикл. Тестовий випадок "lot" (1000 !?) може змусити вас застосувати альтернативний алгоритм для обробки дуже великих чисел.

Поки у вас є лише один тест, мінімально необхідний код, необхідний для проходження тесту, є справді return 120;, і ви можете легко зберегти його до тих пір, поки у вас більше не буде тестів.

Це дозволяє відкласти подальшу розробку, поки ви фактично не напишіть тести, які виконують ІНШІ зворотні значення цього методу.

Будь ласка, пам’ятайте, що тест - це версія, яку можна виконати у вашій специфікації, і якщо все, що зазначено в специфікації, це f (6) = 120, то це цілком відповідає рахунку.

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

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

Розглядайте свої тести на одиницю як прояв вимог - вони повинні спільно визначати поведінку методу, який вони перевіряють. (Це відомо як розвиток, орієнтований на поведінку - його майбутнє ;-))

Тож запитайте себе - якби хтось змінив реалізацію на щось неправильне, чи все-таки пройдуть ваші тести чи вони сказали б "зачекай на хвилину!"?

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

Просто напишіть більше тестів. В кінці кінців, було б коротше писати

public long CalculateFactorial(long input)
{
    return input <= 1 ? 1 : CalculateFactorial(input-1)*input;
}

ніж

public long CalculateFactorial(long input)
{
    switch (input) {
       case 0: return 1;
       case 1: return 1;
       case 2: return 2;
       case 3: return 6;
       case 4: return 24;
       case 5: return 120;
    }
}

:-)

Написання тестів "обману" добре, для досить малих значень "ОК". Але пам’ятайте - тестування одиниць завершено лише тоді, коли всі тести пройдуть і не можуть бути записані нові тести, які не зможуть . Якщо ви дійсно хочете мати метод CalculateFactorial, який містить купу висловлювань if (а ще краще, великий перемикач / випадок case :-), ви можете це зробити, і оскільки ви маєте справу з номером з фіксованою точністю, необхідний код реалізовувати це є кінцевим (хоча, ймовірно, досить великим і некрасивим, можливо, обмеженим компілятором чи системними обмеженнями щодо максимального розміру коду процедури). На даний момент, якщо ви дійснонаполягайте на тому, що вся розробка повинна керуватися одиничним тестом, ви можете написати тест, який вимагає коду для обчислення результату за коротший час, ніж той, який можна виконати, дотримуючись всіх гілок оператора if .

В основному, TDD може допомогти вам написати код, який реалізує вимоги правильно , але він не може змусити вас писати хороший код. Це залежить від вас.

Діліться та насолоджуйтесь.

Я на 100% згоден із пропозицією Роберта Харві, тут справа не лише в тому, щоб пройти тести, потрібно пам’ятати і про загальну мету.

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

Для Факторіалів тест виглядатиме так:

    [Theory]
    [InlineData(0, 1)]
    [InlineData( 1, 1 )]
    [InlineData( 2, 2 )]
    [InlineData( 3, 6 )]
    [InlineData( 4, 24 )]
    public void Test_Factorial(int input, int expected)
    {
        int result = Factorial( input );
        Assert.Equal( result, expected);
    }

Можна навіть реалізувати тестові дані (що повертаються IEnumerable<Tuple<xxx>>) та кодувати математичний інваріант, такий як багаторазове ділення на n дасть n-1).

Я вважаю, що цей tp є дуже потужним способом тестування.

Якщо ви все-таки зможете обдурити, то тестів недостатньо. Пишіть більше тестів! Для вашого прикладу я спробую додати тести з введенням 1, -1, -1000, 0, 10, 200.

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

Проблема з тестовими одиницями полягає в тому, що програмісти іноді розглядають їх як непотрібну роботу. Правильний спосіб їх бачити - це інструмент для того, щоб зробити результат своєї роботи правильним. Отже, якщо ви створюєте "if-then", ви несвідомо знаєте, що є інші випадки, які слід розглянути. Це означає, що вам доведеться написати ще тести. І так далі, і так далі, поки ви не зрозумієте, що обман не працює, і краще просто зашифрувати правильний спосіб. Якщо ти все ще відчуваєш, що не закінчиш, ти не закінчиш.

Я б припустив, що ваш вибір тесту - не найкращий тест.

Я б почав із:

як перший тест, факториал (1),

факторіал (0) як другий

факторіал (-ве) як третій

а потім продовжуйте нерівіальні справи

і закінчити справу з переливом.