Итак, я знаю, что это ... но что это такое точно?
Разработка через тестирование (TDD) и тестирование всегда были терминами, о которых люди вскользь обсуждали и обсуждали достоинства, но я никогда на самом деле не знал, что это такое. Больше всего мне удалось понять, что это был «способ убедиться, что ваш код делает то, что он должен делать», что, хотя и верно, не очень информативно или полезно в на самом деле понимание, что это было и как это делать.
Затем люди начинали подбрасывать такие слова, как заглушка, насмешка и дубли, и я даже меньше понимал, что происходит. Так продолжалось до этапа «Основы» моего учебного лагеря, во время которого я познакомился с этой идеей в относительно безопасной форме.
Для тех из вас, кто в некотором роде знает, что это такое, но не на самом деле, что это такое, я надеюсь, что это поможет вам хотя бы понять основы. Вот что я узнал о том, что на самом деле означает TDD и как его использовать на практике.
Традиционный процесс кодирования будет примерно таким: написать код, посмотреть, что произойдет, делает ли он то, что мы хотим? Нет - ›перепишите код. Да - ›продолжайте жить.
Принимая во внимание, что рабочий процесс TDD будет выглядеть так -
По сути, вы хотите написать тесты, а затем написать максимально простой код, чтобы эти тесты прошли (они должны изначально давать сбой, потому что вы ничего не написали!). После того, как вы пройдете все тесты, вернитесь и реорганизуйте свой код, чтобы сделать его красивее и / или эффективнее.
Ладно, это круто, я понял. Но что это за «тесты», спросите вы? Что они содержат? Что значит «пройти тест»? Я не понимал, как можно написать код, чтобы убедиться, что другой код работает… потому что, написав его, разве вы не сможете определить, работает он или нет?
Допустим, вы хотите написать программу, которая будет говорить: «Привет, [имя]!», Где имя - это любое имя, которое вы ей дадите. (Например. Если вас звали Боб, и вы хотели, чтобы ваша программа поздоровалась с вами, используя ваше имя: «Привет, Боб!»). Если вы не даете своей программе имя, вы хотите, чтобы она говорила: «Привет. , Мир!"
Итак, давайте попробуем эту идею TDD. Идея состоит в том, чтобы сначала написать тесты, прежде чем писать одну строчку кода. Ваши тесты для этой программы могут выглядеть так -
(Различные среды тестирования имеют разный синтаксис для написания тестов; мы пока будем игнорировать фактический синтаксис и сосредоточимся на содержании.)
По сути, этот тест говорит следующее:
- Есть функция под названием «привет»
- Когда вы вызываете hello (), вы должны получить строку «Hello, world!»
- Когда вы вызываете hello () с параметром, вы можете получить строку «Hello, + parameter!»
Как видно из нашей среды тестирования (мы использовали Jasmine и средство запуска тестов Test’em), оба наших теста в настоящее время не работают. Это хорошо; это ожидается!
Теперь наша задача - пройти наши тесты, один за другим, и написать самый простой код, который мы можем сделать, чтобы каждый тест проходил успешно. Наши два теста: «Привет, говорит привет» и «Привет, кому-то привет». Количество строк здесь может сначала показаться пугающим, но ключевые части, на которые следует обратить внимание, - это те, которые находятся в голубых прямоугольниках - они говорят нам, почему наши тесты не проходят, и, в более широком смысле, что мы можем сделать, чтобы исправить Это.
А пока остановимся на первом тесте. Причина, по которой этот тест не прошла, Жасмин объясняет тем, что hello не определен. Итак, давайте попробуем дать определение "привет"!
И если мы оглянемся на наши тесты -
Большой! Теперь у нас другая ошибка, что означает, что происходит что-то другое. Итак, отзыв нашего первого теста гласит: «Ожидаемое значение undefined равно« Hello, world! »». Жасмин сообщает нам, что мы ожидаем, что результат hello () будет равен «Hello, world!», Но вместо этого мы получаем undefined. Давайте попробуем вставить что-нибудь в нашу функцию, которая будет выводить "Hello, world!" когда функция запущена.
Ладно, посмотрим, что случилось.
Один тест пропал! Вверху видно, что из двух спецификаций, с которых мы начали, только одна сейчас не работает! Если мы переключимся в наш список спецификаций -
Мы видим, что надпись «Привет» стала зеленой, что означает, что она прошла успешно. Поздравляю! А теперь перейдем ко второму.
Если вы также заметили, наше сообщение об ошибке изменилось на «Ожидаемое« Hello, world! »На« Hello, Fred! »». Таким образом, это позволяет нам знать, что даже когда мы указываем имя, наша программа по-прежнему говорит нам: «Привет, мир!» (Это не то, чего мы хотим!)
Нам нужен способ ввести имя, и он вернет его нам. Итак, давайте добавим имя в качестве параметра. И похоже, что мы хотим только «Привет, мир!» будет возвращено если мы не укажем имя - так что давайте попробуем использовать оператор if!
И если мы вернемся к нашим тестовым характеристикам -
Ву, они оба проходят! Наша программа работает именно так, как должна.
Преимущества TDD
В течение последних четырех недель моего учебного лагеря нам выдали спецификации тестов, а затем попросили написать код, который позволяет этим тестам проходить. Вот некоторые из преимуществ, которые я лично испытал от этого подхода по сравнению с «традиционным» подходом:
- Это заставляет вас тщательно думать о том, что вам действительно нужно делать, вместо того, чтобы волей-неволей писать кучу функций и смотреть, что происходит. (Что я делал раньше и не рекомендую!)
- Иногда у меня есть дурная привычка пытаться погрузиться во все сразу, и в итоге я сбиваюсь с толку и расстраиваюсь, потому что некоторые проблемы слишком велики, чтобы это сработало! TDD заставляет вас сломать проблему, прежде чем пытаться ее решить. Легко сказать: «Хорошо, моя программа должна делать только одну вещь». И как только у вас есть это одно, вы добавляете еще одно.
- Это позволяет вам точно определить, где ваш код ломается. Если что-то не работает в программе, состоящей из пары сотен строк кода, часто требуется просмотреть все несколько сотен этих строк и записать в консоль почти все, чтобы выяснить, в чем проблема.
- Это делает ваш код гибким, оптимизированным и расширяемым. Вы никогда не пишете код, который вам не нужен, а код, который вы пишете, максимально прост и понятен. У вас всегда есть возможность добавить в существующий код, не опасаясь, что вы сломаете существующий код и не сможете понять, почему.
Недостатки TDD
Единственный недостаток, с которым я лично столкнулся до сих пор, заключался в том, что вам нужно мудро выбирать тестовые случаи. Если вы оставите определенные элементы для тестирования, эти части вашей программы могут работать не так, как вы предполагали. Или, иногда в вашем тестовом примере есть несколько способов получить конечный результат, но вам нужен только один из этих способов.
Например, однажды у меня был тестовый пример, который начинался с массива [0, 1, 2], и я хотел, чтобы я написал функцию, которая изменяла бы этот массив и выводила [0, 3, 6]. Теперь вы можете подумать, что очевидный способ сделать это - умножить каждый элемент на три. Однако я допустил ошибку в своем коде и в итоге умножил каждый из индексов массива на 3, а не каждое число - но тест все равно прошел, потому что в этом случае индексы были то же, что и фактические числа в массиве. Если бы был выбран другой начальный массив, я бы сразу увидел эту ошибку.
* Нельзя сказать, что других недостатков нет; У меня просто еще не было достаточно опыта, чтобы знать из первых рук, что такое другие.
Как мне на самом деле писать тесты?
Итак ... я еще не дошел до этого. Я начал несколько предварительных экспериментов с написанием собственных тестов для небольшого серверного приложения, которое я пытаюсь создать, но я далек от уверенности в своих силах.
(Кроме того, если подумать, возможно, мне стоило попытаться просто написать тесты для существующего приложения, которое у меня есть, вместо того, чтобы пытаться выяснить Node, Express и MongoDB И писать тесты, все в первый раз, но ретроспективно 20–20 , Правильно?)
Что мне делать, если я хочу начать заниматься TDD?
Один из лучших ресурсов, с которыми мне приходилось сталкиваться, - Exercism.io. Он похож на Code Wars или Hacker Rank или на любой другой веб-сайт, посвященный проблемам кодирования, в том, что вы выбираете язык и имеете доступ к хранилищу проблем, которые вы можете решить. Однако, в отличие от Code Wars, Hacker Rank или чего-либо еще, с чем я сталкивался, вместо проблемы со словом вы получаете спецификации теста, и ваше решение проходит, когда все тесты проходят. Для этого потребуется немного настроить систему, но это отличная платформа!
Я также рекомендую просто выбрать среду тестирования и изучить основы и синтаксис, а затем находить сверхлегкие задачи и писать для них тесты.
Дальнейшее чтение
Если вам нужны дополнительные ресурсы, вот некоторые из них, которые, как я считаю, могут помочь понять, что это такое, почему вы должны это делать, и небольшой лакомый кусочек того, как это делать:
Руководство для новичков по разработке через тестирование
Ката - единственный способ научиться TDD
Один странный трюк, который навсегда изменит ваш стиль программирования: JavaScript TDD (не говоря уже о названии Clickbait, это отличный ресурс и есть ссылки на многие другие!)
