LINUX.ORG.RU

История изменений

Исправление fsb4000, (текущая версия) :

Но задание крайне редко задаётся тестами. Как правило задание вида «отсортировать (определение сортированности прилагается) элементы (любого) массива по возрастанию

Сортировка массива идеальное задание для TDD.

Потому что мы можем легко проверить результат даже не зная как сортировать.

Пишутся тесты вида:

for (int i = 0; i < 100; ++i) {
    auto random_vector = generate_random_vector(random(1, 10000));
    auto copy_vector = random_vector;
    my_sort(copy_vector);
    assert(std::ranges::is_sorted(copy_vector));
    assert(std::ranges::is_permutation(copy_vector, random_vector));
}

и всякие граничные случаи, вроде пустого массива, массива где все элементы одинаковые, может ещё какие-нибудь единичные тесты.

property based тесты отлично гармонируют с TDD.

def gcd(p, q):
  if p % 50250 == 0 && q % 50250 == 0:
  ...
  100500 строк
  ...

И вообще, какой-то у тебя китайский TDD. Везде где упоминают TDD, говорят про три шага.

  1. Пишем тест который падает.

  2. Пишем код, чтобы тест проходил.

  3. Рефакторим этот код, чтобы тест по прежнему проходил.

Вся сила TDD, что мы можем любую функцию/класс изменить, и благодаря тестам мы будем уверены что наши изменения не поломали ничего здесь и в других местах.

Видимо с кем ты общался о TDD забывали про третий шаг…

Вот как пример: https://imgur.com/a/wNWun4U

скрины из первого попавшегося видео о TDD: https://youtu.be/_M4o0ExLQCs

Исходная версия fsb4000, :

Но задание крайне редко задаётся тестами. Как правило задание вида «отсортировать (определение сортированности прилагается) элементы (любого) массива по возрастанию

Сортировка массива идеальное задание для TDD.

Потому что мы можем легко проверить результат даже не зная как сортировать.

Пишутся тесты вида:

for (int i = 0; i < 100; ++i) {
    auto random_vector = generate_random_vector(random(1, 10000));
    auto copy_vector = random_vector;
    my_sort(copy_vector);
    assert(std::ranges::is_sorted(copy_vector));
    assert(std::ranges::is_permutation(copy_vector, random_vector));
}

и всякие граничные случаи, вроде пустого массива, массива где все элементы одинаковые, может ещё какие-нибудь единичные тесты.

property based тесты отлично гармонируют с TDD.

И вообще, какой-то у тебя китайский TDD. Везде где упоминают TDD, говорят про три шага.

  1. Пишем тест который падает.

  2. Пишем код, чтобы тест проходил.

  3. Рефакторим этот код, чтобы тест по прежнему проходил.

Вся сила TDD, что мы можем любую функцию/класс изменить, и благодаря тестам мы будем уверены что наши изменения не поломали ничего здесь и в других местах.

Видимо с кем ты общался о TDD забывали про третий шаг…

Вот как пример: https://imgur.com/a/wNWun4U

скрины из первого попавшегося видео о TDD: https://youtu.be/_M4o0ExLQCs