Почему я должен использовать Разработку через тестирование? [дубликат]
var a= [ 'Mon. Dec 10, 2018',
'Mon. Feb 11, 2019',
'Tue. Feb 12, 2019',
'Tue. Aug 13, 2019' ]
var b= [ 'MON. DEC 10', 'MON. FEB 11', 'TUE. FEB 12', 'TUE. AUG 13' ]
// Create new array from array a[]
data: string[] =[];
for(i=0;i<a.length;i++){
data[i]=a[i].split(',').shift(); // spliting 'data[]=['Mon. Dec 10']'
}
// Validation
expect(data).equals(b); // To compare the values
Надеюсь, это поможет вам
11 ответов
Вот три причины, по которым TDD может помочь разработчику / команде:
- Лучшее понимание того, что вы собираетесь писать
- Усиливает политику написания тестов немного лучше
- ] Ускоряет разработку
Одна из причин, по которой сначала нужно написать тесты, - лучше понять реальный код, прежде чем писать его. Для меня это главное преимущество разработки, основанной на тестировании. Когда вы сначала пишете контрольные примеры, вы более критически относитесь к угловым сценариям. Тогда вам будет проще обратиться к ним, когда вы напишите код и убедитесь, что он точен.
Другая причина заключается в том, чтобы фактически заставить писать тесты. Часто, когда люди проводят модульное тестирование без TDD, им настраивают среду тестирования, пишут новый код и затем завершают работу. Они думают, что код уже работает просто отлично, так зачем писать тесты? Это' Достаточно просто, что не сломается, верно? Но теперь вы потеряли преимущества выполнения юнит-тестов (совершенно другое обсуждение). Сначала напишите их, и они уже там.
Написание этих тестов вначале может означать, что вам не нужно запускать программу в среде отладки (медленной - особенно для крупных проектов), чтобы проверить, работают ли несколько мелких вещей. , Конечно, нет оправдания тому, что вы не сделали этого до внесения изменений.
Убедить себя или других людей сначала написать тесты может быть сложно. Возможно, вам повезет больше, если они напишут оба одновременно, что может быть столь же полезным.
он уже там.Написание этих тестов вначале может означать, что вам не нужно запускать программу в среде отладки (медленной - особенно для больших проектов), чтобы проверить, работают ли несколько мелких вещей. Конечно, нет оправдания тому, что вы не сделали этого до внесения изменений.
Убедить себя или других людей сначала написать тесты может быть сложно. Возможно, вам повезет больше, если они напишут оба одновременно, что может быть столь же полезным.
он уже там.Написание этих тестов вначале может означать, что вам не нужно запускать программу в среде отладки (медленной - особенно для больших проектов), чтобы проверить, работают ли несколько мелких вещей. Конечно, нет оправдания тому, что вы не сделали этого до внесения изменений.
Убедить себя или других людей сначала написать тесты может быть сложно. Возможно, вам повезет больше, если они напишут оба одновременно, что может быть столь же полезным.
Общеизвестно, что написание тестов и наличие большого количества автоматизированных тестов - хорошая вещь.
Однако без TDD это часто просто утомительно. Люди пишут тесты, а затем покидают их, и тесты не обновляются должным образом, и новые функции также не тестируются так часто, как следовало бы.
Большая часть этого заключается в том, что код стал болью для test - TDD будет влиять на ваш дизайн, так что его будет легче тестировать. Поскольку вы использовали TDD, у вас есть большое количество тестов, которые значительно облегчают поиск регрессий при каждом изменении кода или требований, значительно упрощая отладку, вызывая приличное понимание хорошего TDD и поощряя писать больше тестов при внесении изменений. нужно - и мы вернулись к началу цикла.
Предположительно, вы тестируете код, который вы написали, прежде чем передать его в репозиторий.
Если это не так, у вас есть другие проблемы, с которыми нужно иметь дело.
Если это правда, вы можете посмотреть на написание тестов с использованием фреймворка как способа автоматизации тех основных подпрограмм или драйверов, которые вы сейчас пишете, чтобы вы могли запустить все они автоматически одним нажатием кнопки. Вам не нужно изучать результаты, чтобы решить, пройден тест или нет; Вы встраиваете успех или провал теста в код и сразу принимаете решение о повышении или понижении. Запуск всех тестов за один раз снижает вероятность возникновения ситуации "ударить крота", когда вы исправляете что-то в одном классе, а что-то другое. Все испытания должны пройти.
Звучит хорошо, пока да?
Люди из TDD просто делают еще один шаг, требуя, чтобы вы написали тест ПЕРВЫЙ, прежде чем писать класс. Конечно, это не получается, потому что вы не написали урок. Это их способ гарантировать, что вы пишете тестовые классы.
Если вы уже используете тестовую среду, получаете хорошую выгоду от написанных вами тестов и имеете значительный охват кода примерно на 70%, то я думаю, что вы дела идут хорошо Я не уверен, что TDD даст вам гораздо большую ценность. Тебе решать, идти ли тебе лишнюю милю. Лично я этим не занимаюсь. Я пишу тесты после уроков и рефакторинг, если чувствую необходимость. Некоторые люди могут посчитать полезным сначала написать тест, зная, что он провалится, но я нет.
Я написал класс. Это их способ гарантировать, что вы пишете тестовые классы.Если вы уже используете тестовую среду, получаете хорошую выгоду от написанных вами тестов и имеете значительный охват кода примерно на 70%, то я думаю, что вы дела идут хорошо Я не уверен, что TDD даст вам гораздо большую ценность. Тебе решать, идти ли тебе лишнюю милю. Лично я этим не занимаюсь. Я пишу тесты после уроков и рефакторинг, если чувствую необходимость. Некоторые люди могут посчитать полезным сначала написать тест, зная, что он провалится, но я нет.
Я написал класс. Это их способ гарантировать, что вы пишете тестовые классы.Если вы уже используете тестовую среду, получаете хорошую выгоду от написанных вами тестов и имеете значительный охват кода примерно на 70%, то я думаю, что вы дела идут хорошо Я не уверен, что TDD даст вам гораздо большую ценность. Тебе решать, идти ли тебе лишнюю милю. Лично я этим не занимаюсь. Я пишу тесты после уроков и рефакторинг, если чувствую необходимость. Некоторые люди могут посчитать полезным сначала написать тест, зная, что он провалится, но я нет.
Я не уверен, что TDD даст вам гораздо большую ценность. Тебе решать, идти ли тебе лишнюю милю. Лично я этим не занимаюсь. Я пишу тесты после уроков и рефакторинг, если чувствую необходимость. Некоторые люди могут посчитать полезным сначала написать тест, зная, что он провалится, но я нет. Я не уверен, что TDD даст вам гораздо большую ценность. Тебе решать, идти ли тебе лишнюю милю. Лично я этим не занимаюсь. Я пишу тесты после уроков и рефакторинг, если чувствую необходимость. Некоторые люди могут посчитать полезным сначала написать тест, зная, что он провалится, но я нет.В идеале:
Вы не будете тратить время на написание ненужных вам функций. У вас будет комплексный пакет модульных тестов, который будет служить защитной сеткой для рефакторинга. У вас будут исполняемые примеры того, как ваш код предназначен для использования. Ваш процесс разработки будет более плавным и быстрым; вы будете тратить меньше времени на отладчик.
Но больше всего ваш дизайн будет лучше. Ваш код будет лучше учтен - слабо связаны, очень сплоченны - и лучше сформированы - меньшие, лучше названные методы и классы.
(Это скорее комментарий, согласующийся с ответом Даффимо, чем его ответ.)
Даффимо отвечает:
Люди из TDD просто делают еще один шаг, требуя, чтобы вы пишете тест, прежде чем писать класс. Конечно, это не получается, потому что вы не написали урок. Это их способ гарантировать, что вы пишете тестовые классы.
Я думаю, что на самом деле это заставляет кодеров задумываться над тем, что делает их код. Необходимость думать о тесте заставляет задуматься о том, что должен делать код: каковы предварительные условия и постусловия, какие функции являются примитивными, а какие состоят из примитивных функций, каков минимально необходимый публичный интерфейс и что детали реализации.
Это все, о чем я обычно думаю, так что, как и вы, «сначала протестируйте» не добавляет много, для меня . И, честно говоря (я знаю, что в некоторых кругах это ересь), мне нравится «привязывать» основные идеи класса, набрасывая сначала общедоступный интерфейс; таким образом я могу посмотреть на это, мысленно использовать его и посмотреть, насколько он чист, как я думал. (Класс или библиотека должны быть простыми и интуитивно понятными для использования клиентскими программистами.)
Другими словами, я делаю то, что TDD пытается обеспечить, выполняя сначала тесты, но, как и duffymo, я получаю по-другому.
И настоящая цель «сначала проверить» - заставить программиста задуматься и подумать, как дизайнер. Глупо делать фетиш из того, как программист входит в это состояние; для тех, кто не делает этого естественным образом, «тест в первую очередь» служит ритуалом, чтобы получить их там. Для тех, кто делает, «сначала тест» не Это может добавить много - и может помешать привычному способу программиста войти в это состояние.
Опять же, мы хотим посмотреть на результаты, а не на ритуалы. Если младшему парню нужен ритуал, «крестные позиции» или четки *, чтобы «войти в паз», «проверка в первую очередь» служит этой цели. Если у кого-то тоже есть свой путь, это тоже замечательно.
Заметьте, я не говорю, что код не должен тестироваться. Должно. Это дает нам сеть безопасности, которая, в свою очередь, позволяет нам сосредоточить наше внимание на написании хорошего кода, даже отважного кода, потому что мы знаем, что сеть существует для отлова ошибок.
Все, что я говорю, это что фетишистская настойчивость «сначала проверить» путает метод (один из многих) с целью , заставляя программиста задуматься о том, что он кодирование.
* Чтобы быть экуменическим, отмечу, что и католики, и мусульмане используют четки. И опять же, это механический способ мышечной памяти, чтобы поставить себя в определенное настроение. Это фетиш (в первоначальном смысле магический объект, а не «сексуальный фетиш») или очарование удачи. Так говорит «Ом мани падме хум», или сидя дзадзэн, или поглаживая «счастливую» кроличью ногу, (Не очень удачно для кролика.) Философ Джерри Фодор, думая о трудных проблемах, имеет подобный ритуал: он повторяет про себя: "Да ладно, Джерри, ты можешь сделать это!" (Я тоже это пробовал, но, поскольку меня зовут не Джерри, у меня это не сработало.;))
SA Механический , способ мышечной памяти, чтобы поставить себя в определенное настроение. Это фетиш (в первоначальном смысле магический объект, а не «сексуальный фетиш») или очарование удачи. Так говорит «Ом мани падме хум», или сидя дзадзэн, или поглаживая «счастливую» кроличью ногу, (Не очень удачно для кролика.) Философ Джерри Фодор, думая о трудных проблемах, имеет подобный ритуал: он повторяет про себя: "Да ладно, Джерри, ты можешь сделать это!" (Я тоже это пробовал, но, поскольку меня зовут не Джерри, у меня это не сработало.;)) SA Механический , способ мышечной памяти, чтобы поставить себя в определенное настроение. Это фетиш (в первоначальном смысле магический объект, а не «сексуальный фетиш») или очарование удачи. Так говорит «Ом мани падме хум», или сидя дзадзэн, или поглаживая «счастливую» кроличью ногу, (Не очень удачно для кролика.) Философ Джерри Фодор, думая о трудных проблемах, имеет подобный ритуал: он повторяет про себя: "Да ладно, Джерри, ты можешь сделать это!" (Я тоже это пробовал, но, поскольку меня зовут не Джерри, у меня это не сработало.;)) или поглаживание «счастливой» кроличьей лапки (Не очень удачно для кролика.) Философ Джерри Фодор, думая о трудных проблемах, имеет подобный ритуал: он повторяет про себя: «Да ладно, Джерри, ты можешь это сделать !» (Я тоже это пробовал, но, поскольку меня зовут не Джерри, у меня это не сработало.;)) или поглаживание «счастливой» кроличьей лапки (Не очень удачно для кролика.) Философ Джерри Фодор, думая о трудных проблемах, имеет подобный ритуал: он повторяет про себя: «Да ладно, Джерри, ты можешь это сделать !» (Я тоже это пробовал, но, поскольку меня зовут не Джерри, у меня это не сработало.;))Я приложил большие усилия для изучения TDD для разработки на Ruby on Rails. Прошло несколько дней, прежде чем я действительно увлекся этим. Я был очень скептичен, но я приложил усилия, потому что программисты, которых я уважаю, поддерживают это.
В этот момент я чувствую, что это определенно стоило усилий. Есть несколько преимуществ, которые, я уверен, другие будут рады перечислить для вас. Для меня наиболее важным преимуществом является то, что это помогает избежать той кошмарной ситуации в конце проекта, когда что-то внезапно ломается без видимой причины, а затем вы проводите полтора дня с отладчиком.
Большинство людей, с которыми я говорил, не используют полную модель TDD. Они обычно находят лучшую модель тестирования, которая работает для них. Найдите свою игру с TDD и найдите, где вы наиболее продуктивны.
Я лично не использую TDD, но один из самых больших плюсов, которые я могу видеть в методологии, заключается в том, что обеспечение удовлетворенности клиентов . По сути, идея заключается в том, что следующие этапы процесса разработки:
1) Поговорите с клиентом о том, что приложение должно делать, и как оно должно реагировать на различные ситуации.
2) Перевести результат 1) в модульные тесты, каждый из которых тестирует одну особенность или сценарий.
3) Написать простой «неаккуратный» код, который (едва) проходит тесты. Когда это будет сделано, вы оправдали ожидания своих клиентов.
4) Измените код, который вы написали в 3), пока не решите, что сделали это наиболее эффективным способом.
Когда это будет сделано, вы надеетесь создать высококачественный код, который соответствует потребностям вашего клиента.
Есть много преимуществ:
- Более высокое качество кода
- Меньше ошибок
- Меньше потерянного времени
Любой из них будет достаточным оправданием для внедрения TDD.
Для моего текущего проекта (который выполняется в относительно тяжелом процессе) я принял особую форму TDD, который состоит из написания тестовых примеров каркаса на основе документов с требованиями и макетов GUI. Я пишу десятки, иногда сотни, прежде чем начинать что-либо реализовывать (это полностью противоречит «чистому» TDD, в котором говорится, что вы должны написать несколько тестов, а затем сразу начать реализацию скелета).
Я обнаружил, что это отличный способ просмотреть документы с требованиями. Я должен думать о поведении, описанном в них, гораздо интенсивнее, чем если бы я просто читал их. В результате я нахожу в них гораздо больше несоответствий и пробелов, которые в противном случае я бы обнаружил только при реализации. Таким образом, я могу попросить разъяснений раньше, и у меня будут лучшие требования, когда я начну внедрять.
Затем, во время реализации, тесты - это способ измерить, как далеко я еще должен идти. И они мешают мне что-то забыть (не смейтесь, это реальная проблема, когда вы работаете над более масштабными вариантами использования).
И мораль такова: даже если ваш процесс разработки не поддерживает TDD, он все еще может быть сделано таким образом, и улучшить качество и производительность.
Я должен думать о поведении, описанном в них, гораздо интенсивнее, чем если бы я просто читал их. В результате я нахожу в них гораздо больше несоответствий и пробелов, которые в противном случае я бы обнаружил только при реализации. Таким образом, я могу попросить разъяснений раньше, и у меня будут лучшие требования, когда я начну внедрять.Затем, во время реализации, тесты - это способ измерить, как далеко я еще должен идти. И они мешают мне что-то забыть (не смейтесь, это реальная проблема, когда вы работаете над более масштабными вариантами использования).
И мораль такова: даже если ваш процесс разработки не поддерживает TDD, он все еще может быть сделано таким образом, и улучшить качество и производительность.
Я должен думать о поведении, описанном в них, гораздо интенсивнее, чем если бы я просто читал их. В результате я нахожу в них гораздо больше несоответствий и пробелов, которые в противном случае я бы обнаружил только при реализации. Таким образом, я могу попросить разъяснений раньше, и у меня будут лучшие требования, когда я начну внедрять.Затем, во время реализации, тесты - это способ измерить, как далеко я еще должен идти. И они мешают мне что-то забыть (не смейтесь, это реальная проблема, когда вы работаете над более масштабными вариантами использования).
И мораль такова: даже если ваш процесс разработки не поддерживает TDD, он все еще может быть сделано таким образом, и улучшить качество и производительность.
Я нахожу в них гораздо больше несоответствий и пробелов, которые иначе я бы обнаружил только во время реализации. Таким образом, я могу попросить разъяснений раньше, и у меня будут лучшие требования, когда я начну внедрять.Затем, во время реализации, тесты - это способ измерить, как далеко я еще должен идти. И они мешают мне что-то забыть (не смейтесь, это реальная проблема, когда вы работаете над более масштабными вариантами использования).
И мораль такова: даже если ваш процесс разработки не поддерживает TDD, он все еще может быть сделано таким образом, и улучшить качество и производительность.
Я нахожу в них гораздо больше несоответствий и пробелов, которые иначе я бы обнаружил только во время реализации. Таким образом, я могу попросить разъяснений раньше, и у меня будут лучшие требования, когда я начну внедрять.Затем, во время реализации, тесты - это способ измерить, как далеко я еще должен идти. И они мешают мне что-то забыть (не смейтесь, это реальная проблема, когда вы работаете над более масштабными вариантами использования).
И мораль такова: даже если ваш процесс разработки не поддерживает TDD, он все еще может быть сделано таким образом, и улучшить качество и производительность.
нам еще предстоит И они мешают мне что-то забыть (не смейтесь, это реальная проблема, когда вы работаете над более масштабными вариантами использования).И мораль такова: даже если ваш процесс разработки не поддерживает TDD, он все еще может быть сделано таким образом, и улучшить качество и производительность.
нам еще предстоит И они мешают мне что-то забыть (не смейтесь, это реальная проблема, когда вы работаете над более масштабными вариантами использования).И мораль такова: даже если ваш процесс разработки не поддерживает TDD, он все еще может быть сделано таким образом, и улучшить качество и производительность.
TDD (Test Driven Development / Design) обеспечивает следующие преимущества
- гарантирует, что вы знаете критерии приемлемости карты-истории перед запуском
- , гарантирует, что вы знаете, когда следует прекратить кодирование (т. Е. при соблюдении критериев приемки предотвращает «золотое покрытие»)
В результате вы получаете код, который
- тестируемый
- чистый дизайн
- , который можно с уверенностью реорганизовать
- минимально необходимый код чтобы удовлетворить карточку рассказа
- живая спецификация того, как работает код
- , способная поддерживать устойчивый темп новых функций