Разработка через тестирование: улучшаем навыки

https://medium.freecodecamp.org/how-to-get-better-at-testing-with-test-driven-development-18a7d097b23f
Тестирование важный навык, которым должен обладать каждый разработчик. Тем не менее, некоторые делают это неохотно.

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

image

Тесты делают ваш код стабильнее и уменьшают количество багов. Вам кажется, что это не так, потому что вы знаете каждый бит вашего кода. Ведь вы же его и написали, зачем еще тесты?

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

Теперь представим, что вы закончили работу над приложением и вернетесь к нему через несколько месяцев. Вы не будете помнить каждую деталь старого кода. Вы измените его… и черт возьми… что-то сломалось. Как вы это исправите? Посмотрите на каждый созданный файл и настроите его, чтобы он снова работал? Может и получится. Но изменив этот файл, вы сломаете что-то еще.

Возьмем еще один пример. После нескольких месяцев напряженной работы, вы наконец получили позицию, которую давно хотели! Вы включаетесь в команду и начинаете что-то создавать. Вы работаете с кодом других разработчиков и наоборот. И в один день все ломается. Если команда не интегрировала тесты в свое приложение, я вам не завидую.

Каждая команда должна писать тесты, когда создает программное обеспечение или приложения. Вы же не хотите быть человеком, который не знает, как тестировать?

Да, написание тестов требует времени. Да, сначала сложно. Да, создавать приложения интереснее. Но тесты важны и экономят время, если они правильно реализованы.

Моя цель сегодня: улучшить навыки тестирования. Мы рассмотрим unit тестирование и разработку через тестирование с помощью Jest (инструмент тестирования JavaScript). Конечно, есть другие инструменты тестирования, которые вы можете использовать, например, Mocha и Chai.

Давайте начнем!

Unit тестирование


Когда вы решаете протестировать приложение, вы сталкиваетесь с различными типами тестирования: unit тестирование (модульное), интеграционные тесты и функциональные тесты. Остановимся на модульных тестах.

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

Преимущества модульного тестирования:

  • Делает код стабильнее;
  • Облегчает изменения реализации функции без изменения ее поведения;
  • Документирует ваш код. Вы скоро поймете, для чего.
  • Заставляет вас делать правильно проектировать. Действительно, плохо разработанный код часто сложнее тестировать.

Разработка через тестирование (TDD)

Чтобы понять и использовать разработку через тестирование, запомните эти 2 правила:

  1. Пишите тест, который не проходит, до написания кода.
  2. Затем пишите код, который сможет пройти тест.

Когда мы используем TDD, мы говорим о цикле “red, green, refactor”.

Red: вы пишите провальный тест без написания кода.

Green: пишите простейший код, который сможет пройти тест. Даже если код кажется вам наиглупейшим.

Refactor: рефакторинг кода, если необходим. Не беспокойтесь, если вы поменяете код и ваши юнит-тесты сломаются, если что-то пойдет не так.

Структурирование тестового файла


Jest предоставляет функции для структурирования тестов:

describe: используется для группировки ваших тестов и описания поведения вашей функции/модуля/класса. Он принимает два параметра. Первый — это строка, описывающая вашу группу. Второй — это функция обратного вызова, в которой у вас есть тестовые примеры или hook функции.

it или test: ваш модульный тест. Параметры такие же как и у describe. Должен быть описательным. Именование теста зависит от вас, но можно начинать с «Should».

beforeAll (afterAll): hook функция запускает до (и после) все тесты. Принимает один параметр, который является функцией, которую вы будете запускать до (и после) всех тестов.

beforeEach (afterEach): hook функция, которая выполняется до (и после) каждого теста. Принимает один параметр, который является функцией, которую вы будете запускать до (и после) каждого теста.

Перед тем, как писать любой тест, вы должны знать следующее:

Вы можете пропустить тест, используя .skip на describe и it: it.skip(...) или describe.skip(...). Используя .skip, вы говорите Jest игнорировать тест или группу.

Вы можете выбрать именно те тесты, которые хотите запустить, используя .only на describe и it: it.only(...) или describe.only(...). Это полезно, если у вас много тестов и вы хотите сосредоточиться только на одном или хотите «отладить» ваши тесты.

Настройка Jest


Чтобы показать вам те функции тестирования, которые мы рассматривали выше, нам нужно настроить Jest. Это очень просто.

Вам нужны только Node.js и npm или Yarn. Убедитесь, что вы используете последнюю версию Node.js, поскольку мы будем использовать ES6. Создайте новый каталог и инициализируйте его.

mkdir test-example && cd test-example
npm init -y
# OR
yarn init -y

-y отвечает “да” на все вопросы npm или yarn. Он должен был создать очень простой файл package.json.

Затем добавьте Jest в среду разработки

yarn add jest --dev

Затем добавьте следующий скрипт в ваш package.json:

"scripts": {
  "test": "jest"
}

yarn test будет запускать ваши тестовые файлы в каталоге. По умолчанию Jest распознает файлы, находящиеся внутри каталога __tests__, или файлы, которые заканчиваются на .spec.js, либо .test.js.

На этом все. Вы готовы писать первый тест.

Matchers (образцы)


Когда вы что-то проверяете, вам нужен вход и ожидаемый результат. Вот почему Jest предоставляет образцы для проверки наших значений:

expect(input).matcher(output)

Jest имеет много образцов, вот самый важный:

toBe: сравнивает strict equality (===).

expect(1 + 1).toBe(2)
let testsAreEssential = true
expect(testAreEssential).toBe(true)

toEqual: сравнивает значения между двумя переменными, массивами или объектами.

let arr = [1, 2]
arr.push(3)
expect(arr).toEqual([1, 2, 3])
let x= 1
x++
expect(x).toEqual(2)

toBeTruthy (toBeFalsy): указывает, истинно ли значение (или ложно).

expect(null).toBeFalsy()
expect(undefined).toBeFalsy()
expect(false).toBeFalsy()
expect("Hello world").toBeTruthy()
expect({foo: 'bar'}).toBeTruthy()

toContain: проверяет, содержит ли массив элемент.

expect(['Apple', 'Banana', 'Strawberry']).toContain('Apple')

toThrow: проверяет, вызывает ли функция ошибку.

function connect () {
  throw new ConnectionError()
}
expect(connect).toThrow(ConnectionError)

Первые тесты


Теперь мы собираемся написать наш первый тест и поиграть с нашими функциями. Сначала создайте в своем каталоге файл example.spec.js и вставьте следующее:

describe('Example', () => {
  beforeAll(() => {
    console.log('running before all tests')
  })
  afterAll(() => {
    console.log('running after all tests')
  })
  beforeEach(() => {
    console.log('running before each test')
  })
  afterEach(() => {
    console.log('running after each test')
  })
  it('Should do something', () => {
    console.log('first test')
  })
  it('Should do something else', () => {
    console.log('second test')
  })
})

Обратите внимание, что нам не нужно импортировать все функции, которые мы используем. Они уже предоставлены Jest.

Запустите yarn test:

image

Поскольку у вас нет утверждений в тестах, они пройдут. Вы видели разные инструкции console.log? Вы должны лучше понимать, как работают ваши функции и тестовые примеры.

Теперь удалите все hook функции и добавьте .skip в первый тест:

describe('Example', () => {
  it.skip('Should do something', () => {
    console.log('first test')
  })
  it('Should do something else', () => {
    console.log('second test')
  })
})

Запустите yarn test еще раз:

image

Ничего страшного, если первый тест работать не будет.

Добавьте третий тест и используйте .only:

describe('Example', () => {
  it('Should do something', () => {
    console.log('first test')
  })
  it('Should do something else', () => {
    console.log('second test')
  })
  it.only('Should do that', () => {
    console.log('third test')
  })
})

Еще раз запустим yarn test:

image

Во второй части статьи мы сделаем простую реализацию стека в JavaScript с помощью TDD.
Поделиться публикацией

Похожие публикации

Комментарии 25

    0
    вы пишите провальный тест без написания кода.

    Это работает для первого теста. Но что делать со вторым, третьим, десятым? Что делать, когда ты не можешь написать ни одного красного теста, так как код сейчас работает верно, но тестовые сценарии покрыты определённо не все?


    рефакторинг кода, если необходим. Не беспокойтесь, если вы поменяете код и ваши юнит-тесты сломаются, если что-то пойдет не так.

    Как же тут не беспокоиться, если ранее мы не смогли написать красных тестов, оставив не все тестовые сценарии покрытыми?

      0
      > Что делать, когда ты не можешь написать ни одного красного теста, так как код сейчас работает верно, но тестовые сценарии покрыты определённо не все?

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

          Выделяю, то, что вы не заметили:


          Но что делать со вторым, третьим, десятым? Что делать, когда ты не можешь написать ни одного красного теста, так как код сейчас работает верно, но тестовые сценарии покрыты определённо не все?

          Вы можете писать тесты на каждое входное значение

          Ещё подробнее надо? TDD не о тестировании всех классов эквивалентности или всех возможных значений. TDD не допускает написания ожидаемо зелёных тестов в рамках реализации поведения модуля, но не запрещает их писать вне этого процесса.


          Пишите хоть на каждую комбинацию входных значений тесты, которые ожидаемо будут зелёными, но не называйте это частью TDD и всё. Или ломайте код перед тем как писать ожидаемо зелёный тест, так чтобы все остальные тесты остались зелёными, а новый был красным.

            0

            Ну, давайте и я выделю для вас то, что вы не заметили:


            Как же тут не беспокоиться, если ранее мы не смогли написать красных тестов, оставив не все тестовые сценарии покрытыми?

            А подробней хотелось бы не рассказы о том, что ТДД разрешает или запрещает, и что можно называть ТДД, а что нельзя. Расскажите лучше какие проблемы ТДД решает и обоснуйте каким образом это следует из накладываемых ТДД ограничений.

              0

              Мне казалось очевидным, что ответ на второй вопрос: "после ответа на первый, второй вопрос не имеет смысла".


              TDD решает проблему начала написания кода до уверенности в понимании требований, а также решает проблему низкого покрытия кода тестами, причём не формального, а реального. TDD не единственный инструмент для этого, но работающий. Есть ещё "бесплатные плюшки" у TDD

                0
                TDD решает проблему начала написания кода до уверенности в понимании требований

                Каким образом лишь частичное написание тестов даёт уверенность в понимании требований?


                решает проблему низкого покрытия кода тестами

                Каким образом частичное покрытие тестовых сценариев решает проблему низкого покрытия?


                Есть ещё "бесплатные плюшки" у TDD

                О которых вы нам не расскажете?

                  0
                  даёт уверенность в понимании требований?

                  "уверенность" понятия субъективное. Суть в том что бы разработчик начал формулировать требования ДО написания кода. Если уверенности в понимании требований нет — пишите больше тестов, есть уверенность в понимании — возможно тестов уже достаточно.


                  У Кента Бэка в его книге про разработку через тестирование было об этом, мол длина итераций красный-зеленый-рефакторинг зависит от вашей уверенности. Ну и в целом он в своей книге пишет что это все способ борьбы со страхом внесения изменений.


                  Опять же, способ этот не универсален и он хорошо работает на ком-то вроде Кента Бэка, но может плохо работать для кого-нибудь другого. Ну и не для всех задач такой способ подойдет. Универсальных вещей в этом плане как бы нету.


                  решает проблему низкого покрытия?

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


                  О которых вы нам не расскажете?

                  Не могу говорить за VolCh но… для меня тесты в TDD это та самая "бесплатная" вещь. А главная цель для меня все же в формализации требований и проектировании интерфейсов (ибо тесты это тот же клиентский код). Тесты такие на ранних этапах будут намекать нам о связанности лишней, о том что с декомпозицией что-то не так пошло и т.д.


                  p.s. я не очень понимаю вашу позицию. Вы хотите затеять очередной холивар нужен ли TDD? А зачем? подход не претендует на универсальность а его плюсы, минусы и прочее разжеваны в 5-ти часовом холиваре DDH, Кента Бэка и Фаулера (Is TDD Dead). Есть еще TDD vs DbC с дядей Бобом и Джимом Копленом.


                  Ну либо накиньте что-то конкретное.

                    0
                    Суть в том что бы разработчик начал формулировать требования ДО написания кода.

                    Не просто формулировать требования. А формулировать их формально. В чём преимущество перед пост-формализацией?


                    Ну и в целом он в своей книге пишет что это все способ борьбы со страхом внесения изменений.

                    Что именно является способом борьбы со страхом внесения изменений? Формулирование требований до написания кода или всё же полнота покрытия тестами?


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

                    Если измерять покрытие строчек кода, то ваше утверждение может быть и верно. Но как это может обеспечить достаточное покрытие хотя бы классов эквивалентности?


                    тесты в TDD это та самая "бесплатная" вещь.

                    Какая ж она бесплатная, если вы на их написание требуется время и силы? И тратится независимо от того пишутся ли тесты до или после. Причём есть гипотеза, что писать тесты на отсутствующий код несравнимо сложнее, чем на существующий.


                    Вы хотите затеять очередной холивар нужен ли TDD?

                    Я хочу понять каким именно образом заявляемые плюсы вытекают из предлагаемых ограничений. Но рациональная обезьянка в моей голове никак не улавливает логического следствия одного из другого.

                      0
                      В чём преимущество перед пост-формализацией?

                      В проверке соотвествия кода формальным требованиям до разработки. Исключение (пускай минимизация частоты) ситуаций типа "блин, я при формализации требований обнаружил, что неправильно понял их неформализованный вариант — теперь всё полностью переделывать надо"


                      Формулирование требований до написания кода или всё же полнота покрытия тестами?

                      В комплексе. Но больше не столько "физическая" полнота покрытия, сколько уверенность, в том что требования покрыты тестами, и если тесты после изменений не падают, то значит требования всё ещё выполняются. А 100% кода тестами покрыто или 1% — не суть.


                      Но как это может обеспечить достаточное покрытие хотя бы классов эквивалентности?

                      Если требования покрывают классы эквивалентности в терминах бизнес-требований, то и тесты их покроют в этих терминах.


                      Какая ж она бесплатная, если вы на их написание требуется время и силы? И тратится независимо от того пишутся ли тесты до или после.

                      В TDD тесты часть процесса разработки, когда разработку завершили, то тесты уже есть основные и тратить на них время не нужно. И не получится "сроки горят, давай в релиз ведь вроде работает, тесты потом напишем". Когда написание тестов выделено в отдельный этап после собственно разработки, есть большой соблазн не писать тесты или писать их "для галочки".


                      Причём есть гипотеза, что писать тесты на отсутствующий код несравнимо сложнее, чем на существующий.

                      Практика эту гипотезу обычно опровергает. Одним из главных плюсов TDD и ко как раз считается, что они форсят создание легкотестируемого кода (вернее простых для тестирования API), если разработчики не мазохисты :) Вам, наверное, известно, какая мука покрывать тестами большинство легаси кода, особенно юнит-тестами.

                        0
                        В чём преимущество перед пост-формализацией?

                        Тем что реализация не влияет на процесс формализации требований, и от того меньше технических деталей в эти требования проникает. Как следствие, поскольку речь идет о юнит тестах, больше шансов спроектировать более изолированные контракты.


                        Когда разработчики, особенно те кто только начинают писать тесты, пишут тесты после реализации, чаще всего эти тесты тупо дублируют реализацию.


                        Что именно является способом борьбы со страхом внесения изменений?

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


                        Но как это может обеспечить достаточное покрытие хотя бы классов эквивалентности?

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


                        Какая ж она бесплатная, если вы на их написание требуется время и силы?

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


                        Тут стоит сделать ремарку — если вы УЖЕ можете делать более изолированные модули, вы УЖЕ умеете писать тесты неплохо, вы понимаете как определять их качество и т.д. то ценности от TDD для вас возможно нет.


                        Причём есть гипотеза, что писать тесты на отсутствующий код несравнимо сложнее, чем на существующий.

                        Кент Бэк в своей книге (опять же нет под рукой, не могу дать точную отсылку) писал о маленьком исследовании где эта гипотиза по сути опровергается. Там типа ставился эксперемент в духе пишем одно и то же приложение 10 раз (что-то простенькое, консольная симуляция игры в боулинг например), половина тесты до, половина тесты после, засекаем время и т.д.


                        Опять же — я не смог нагуглить полноценных исследований на эту тему. Но в целом (во всяком случае на основании моих опытов) я могу объяснить это за счет того, что в случае TDD у нас этап написания тестов и этап формализации требований (а он есть всегда вне зависимости от подхода) — один и тот же этап, что позволяет меньше переключать контекст. Ну и еще одно интересное наблюдение — писать тесты после реализации обычно скучнее (опять же судить могу только по себе и людям с которыми когда-то эти темы обсуждал).

                      +1
                      Каким образом лишь частичное написание тестов даёт уверенность в понимании требований?

                      Про частичное написание тестов я ничего не говорил. Есть требование — формулируем его на языке тестов. Все требования (функциональные, конечно) формулируем. Код пишем минимально необходимый для прохождения теста. Причём минимально необходимый не означает минимально физически, в символах кода, а минимально логический. Например, в функция деления для параметров 4 и 2 ловим исключение деления на ноль, а не выбрасываем его в тест. Когда встретим требование, описывающее деление на ноль — тогда обработаем как в требованиях указано.


                      Каким образом частичное покрытие тестовых сценариев решает проблему низкого покрытия?

                      Мы не делаем частичное покрытие тестовых сценариев, у нас даже понятия такого нет. Вы делаете? Зачем? Тестовые сценарии у QA, мы работаем с требованиями и не покрываем их, а переводим на формальный язык тестов, после чего имплементируем.


                      TDD способствует низкой связанности и высокой связности, TDD улучшает документирование, TDD статистически снижает время на отладку

                        0
                        Про частичное написание тестов я ничего не говорил.

                        Это я уже заметил, что адепты TDD просто не видят проблему :-) Вы исходите из предпосылки, что невозможность написать красный тест означает, что покрытие достигло своей полноты. Однако, это не так. Причинно-следственная связь тут есть лишь с тем, что реализация в данный момент удовлетворяет всем требованиям. Но из этого никак не вытекает, что тесты покрывают все кейсы, а значит делает любой рефакторинг довольно рискованным занятием, требующим повторной сверки всех требований с написанием новых красных тестов.


                        в функция деления для параметров 4 и 2 ловим исключение деления на ноль, а не выбрасываем его в тест.

                        Вы очень непонятно написали.


                        Тестовые сценарии у QA, мы работаем с требованиями и не покрываем их, а переводим на формальный язык тестов

                        Вы сейчас просто жонглируете терминами, вместо того, чтобы услышать, что вам говорит собеседник.


                        TDD способствует низкой связанности и высокой связности, TDD улучшает документирование, TDD статистически снижает время на отладку

                        Опять голословные лозунги в стиле Геббельса. Вы можете обосновать каким образом написание тестов до кода на всё это влияет?

                          0
                          Вы исходите из предпосылки, что невозможность написать красный тест означает, что покрытие достигло своей полноты.

                          Нет. Это ещё так же может означать, что или требования друг друга перекрывают, или была проведена преждевременная имплементация. Как раз про очень непонятно написанное: Есть два требования:


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

                          Пишем первый тест, что div(4,2) === 2 — красный
                          Пишем наивную имплементацию return a/b — зелёный;
                          Пишем второй тест, что div(4,0) бросает исключение — зелёный


                          Вывод — первая имплементация неверная, в первом требовании ничего про исключения нет, а мы их бросаем. Меняем имплементацию так, чтобы первый тест оставался зелёным, а второй стал красным, чтоб исключений не смог поймать. Ну а потом меняем имплементацию так, чтобы и второй стал зелёным. Имплементация становится той же, что и была изначально, но мы убедились в работоспособности второго теста.


                          Вы можете обосновать каким образом написание тестов до кода на всё это влияет?

                          Одно обосновал выше, программисты — не мазохисты, не будут писать тесты со сложным флоу инициализации. Документация — тесты и есть документация. Отладка — во-первых, там было слово "статистически", во-вторых, можно предположить, что статистика эта обусловлена, как минимум, тем, что разработка производится небольшими кусочками и в большинстве случаев и так очевидно, где ошибка, что не требует включения отладчика или скажем, усилиннего логирования.

                            0
                            Вывод — первая имплементация неверная, в первом требовании ничего про исключения нет, а мы их бросаем.

                            Опять же, на примерах функции деления плохо просматривается суть зачем так делать. Ну я к тому что если разработчик чувствует уверенность он может существенно увеличить длину итерации (написать сразу 2-3 теста, скипнуть часть про "всегда должен быть красный тест" и т.д.) Ну и обычно уверенность уменьшается пропорционально сложности задачи.


                            Словом, Кент Бэк все это придумывал что бы регулируя длину итераций чувствовать себя уверенно в коде. Кому-то это для уверенноси не нужно, а кому-то — недостаточно только этого.

            +1
            Что делать, когда ты не можешь написать ни одного красного теста, так как код сейчас работает верно

            Напишите зеленый тест, ограничение же действует на реализацию а не на тесты. Единственная причина по которой вы можете захотеть добавить новый тест — вы хотите закрепить еще одно требование. В этом случае не важно, реализовано оно уже или нет. Важно что бы вы не добавлялии в реализацию вещей для которых требования в тестах не закреплены.


            Правило что нужно убедиться красный ли тест или нет оно как раз об этом. Если внезапно он окажется зеленым — чудно! Вроде даже у Бэка в книге был расписан пример ситуации в которую он попал не проверив что тест уже зеленый (он начал менять код и тесты падали, а потом оказалось что код можно было не менять).


            но тестовые сценарии покрыты определённо не все?

            добавлять больше зеленых тестов вам никто не запрещает. Просто это будет уже увеличение покрытия не влияющее на дизайн кода. Опять же именно по этому принципу построена "триангуляция".

              0
              Не помню где читал рекомендацию, что при сомнениях в том, что новый тест должен быть зелёным очень серьёзно надо проверять и код, и тест на ошибки. Ошибки гораздо чаще встречаются чем чудеса :)

              И даже встречал рекомендацию при уверенности что тест должен быть зелёным (например, проверить, что при делении на ноль исключение бросает, когда точно знаешь что оно бросится), сначала изменить код чтобы ожидаемого поведения не было и тест таки получился красным, а потом вернуть код как был. Тогда будет больше уверенности, что тест вообще что-то тестирует.
                0
                Единственная причина по которой вы можете захотеть добавить новый тест — вы хотите закрепить еще одно требование.
                Если внезапно он окажется зеленым — чудно!

                Вы вот правильные вещи пишете, но к TDD они имеют мало отношения :-) Зелёный тест — это по факту написание теста после реализации, что не является TDD по определению.


                Важно что бы вы не добавлялии в реализацию вещей для которых требования в тестах не закреплены.

                Эти вещи естественным образом появляются как побочный эффект от реализации других вещей. Даже если мы пишем минимальный проходящий тесты заведомо некорректный код.

                  0
                  > Эти вещи естественным образом появляются как побочный эффект от реализации других вещей. Даже если мы пишем минимальный проходящий тесты заведомо некорректный код.

                  Значит при неожиданном появлении зелёного теста нужно сначала избавиться от побочных эффектов, дающих зелёность, а потом, получив красный, работать как обычно.
                    0

                    Вы предлагаете написать дополнительный код, чтобы сломать тест, а потом его удалить, чтобы починить? И Что вам даст эта карго-практика?


                    Давайте на более конкретном примере..


                    Первый тест красный:


                    assert( toGrid( 22.5 ) === 20 ) )

                    Реализация и тест зеленеет:


                    function toGrid( x : number ) {
                        return Math.floor( x / 10 ) * 10
                    }

                    Второй тест сразу зелёный:


                    assert( toGrid( -22.5 ) === -30 ) )

                    Ваши действия?

                      0
                      В этой ситуации я бы сразу написал два теста изначально, если бы оба требования сразу были. Ну а если по каким-то причинам второе требование пришло сильно позже второго и точным указанием имплементировать, и какая-нибудь CI не даёт просто написать тест, то обернул бы, например, в abs всё, написал бы тест, он сломался, закоммитил, а потом удалил abs и получил бы зелёный. И у всей команды была бы уверенность, что второй тест реально что-то тестирует.
                        +1
                        я бы сразу написал два теста изначально, если бы оба требования сразу были

                        То есть вы сразу пишете все тесты, а потом всю реализацию? Мужественно. Но вы уверены, что такой подход можно назвать TDD?


                        CI не даёт просто написать тест

                        Вы не думали, что такую CI стоит сразу выкинуть?


                        обернул бы, например, в abs всё, написал бы тест, он сломался, закоммитил, а потом удалил abs и получил бы зелёный

                        Часто бывает очень сложно сломать ровно один тест из пары десятков. Вы уверены, что стоит тратить рабочее время на подбор такого намеренно дефективного алгоритма?


                        у всей команды была бы уверенность, что второй тест реально что-то тестирует

                        Ну, что-то он тестирует. А то ли он тестирует? Тестирует ли он что-то помимо отсутствия того дефекта, что вы вручную добавляли? Например, тавтологический тест:


                        assert( toGrid( -22.5 ) === toGrid( -22.5 ) ) )

                        И добавленный карго-дефект:


                        function toGrid( x : number ) {
                            if( x < 0 ) return Number.NaN
                            return Math.floor( x / 10 ) * 10
                        }

                        Перестанет ли тест быть тавтологическим, если мы последовательно добавим и удалим сей дефект?

                          0
                          > Вы не думали, что такую CI стоит сразу выкинуть?

                          Этот процесс долго и сознательно настраивали, когда решили ввести TDD в команде которая вообще до этого тесты не практиковала практически. Для девопсов такая постановка задачи была своеобразным вызовом даже.

                          > Но вы уверены, что такой подход можно назвать TDD?

                          Если не подходить очень формально к TDD, а гибко, то вполне можно так называть — разработка основана на тестах, код не пишется без красных тестов. Всё, конечно, от задач зависит, от их сложности. Какие-то элементарные вещи типа геттеров-сеттеров можно десятками тесты писать, не запуская, понимая, что они упадут, потому что реализации тупо нет, потом сделать реаализацию и убедиться что весь десяток зелёный.

                          > Часто бывает очень сложно сломать ровно один тест из пары десятков. Вы уверены, что стоит тратить рабочее время на подбор такого намеренно дефективного алгоритма?

                          Всё зависит от процесса, но написание заведомо зелёного теста к TDD отношения не имеет, по-моему — обычное покрытие тестами готового кода.

                          > Перестанет ли тест быть тавтологическим, если мы последовательно добавим и удалим сей дефект?

                          Общие подходы к тестированию и разработки TDD не отменяет, в частности она рассчитана на разумных людей, а не «троллей», которые могут на каждый тест-кейс захардкодить возврат ожидаемого значения, а на всех остальных сделать де-факто undefined behavior. С другой стороны, этот тест не тавтологическим может быть, а грубой проверкой того, что функция чистая.
                            0
                            То есть вы сразу пишете все тесты, а потом всю реализацию?

                            Вы правильно заметили на тему "мужественности". Но все же от "все тесты" это все очень далеко. Я как-то общался с человеком которому не нравилось TDD потому что он месяц тесты писал и только потом писал реализацию. Сами понимаете как это не эффективно.


                            На тему же "мужественности" — для простых задач можно сразу накидать несколько тест кейсов (триангуляция, в терминах Кента Бэка) и потом реализовывать код. И чаще всего вы врядли захотите двигаться совсем уж маленькими шагами. А вот если вы написали несколько тестов и не можете написать код — всегда можно убрать пару тестов и двигаться более маленькими шажками. Тут все очень субъективно. По сути основной момент — насколько вы уверены. Не уверены — сокращайте длину итераций.


                            Вы уверены, что стоит тратить рабочее время на подбор такого намеренно дефективного алгоритма?

                            Возможно VolCh меня поправит, но мне кажется речь идет о ситуации когда изменения вносятся в код, который писался давно и как следствие разработчику лучше разобраться почему то поведение которого вроде бы небыло (иначе зачем тест) — работает.


                            да, довольно часто это все избыточно (опять же смотрим про уверенность), но если уверенности нет — имеет смысл.


                            Правда я не соглашусь с тем что бы заставлять людей так делать, в большинстве случаев это действительно избыточно.


                            Ну, что-то он тестирует. А то ли он тестирует?

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

                              0
                              почему то поведение которого вроде бы небыло (иначе зачем тест) — работает.

                              Тест потому что пришло новое требование и да, особая польза есть в случаях "легаси" кода. С одной стороны вроде уже работает, а с другой непонятно почему требование новое появилось. Разобраться в ситуации полезно в любом случае.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое