Модульные тесты должны быть записаны, прежде чем код написан?
Я не уверен точно, но попробуйте этот стиль. следует начать:
table /deep/ td:first-child {
border-right: 1px solid black;
}
19 ответов
Некоторые хорошие комментарии здесь, но я думаю, что одна вещь становится проигнорированной.
запись тестирует первые диски Ваш дизайн. Это - важный шаг. Если Вы пишете тесты "одновременно" или "вскоре после того, как" Вы могли бы пропускать некоторые преимущества дизайна выполнения TDD на микро шагах.
Это чувствует себя действительно дрянным сначала, но удивительно наблюдать, что вещи разворачиваются на Ваших глазах в дизайн, о котором Вы не думали первоначально. Я видел, что он происходит.
TDD тверд, и это не для всех. Но если Вы уже охватываете поблочное тестирование, затем испытываете его в течение месяца и видите то, что оно делает к Вашему дизайну и производительности.
Вы проводите меньше времени в отладчике и больше времени, думая о внешней стороне - в дизайне. Те - два гигантских плюса в моей книге.
Помогает, когда Вы пишете что-то, что Вы используетесь, пишущий для записи сначала всей вещи, которую Вы регулярно проверяли бы на и затем писали бы те функции. Больше раз тогда не те функции являются самыми важными для части программного обеспечения, которое Вы пишете. Теперь, с другой стороны нет серебряных пуль, и вещь никогда не должна сопровождаться к букве. Суждение разработчика играет большую роль в решении об использовании разработки через тестирование по сравнению с тестом последняя разработка.
Я пишу им одновременно. Я создаю скелетный код для нового класса и тестового класса, и затем я пишу тест для некоторой функциональности (который тогда помогает мне видеть, как я хочу, чтобы новый объект был назван), и реализуйте его в коде.
Обычно, я не заканчиваю с изящным кодом в первый раз вокруг, это обычно вполне hacky. Но как только все тесты работают, можно осуществить рефакторинг далеко, пока Вы не заканчиваете с чем-то довольно аккуратным, опрятным и доказуемым, чтобы быть горным телом.
Да, если Вы используете истинные принципы TDD. Иначе пока Вы пишете модульные тесты, Вы добиваетесь большего успеха, чем большинство.
, По моему опыту, обычно легче записать тесты перед кодом, потому что путем выполнения его тот способ, которым Вы даете себе простое средство отладки для использования, поскольку Вы пишете код.
Помните с Экстремальным программированием, Ваши тесты effectly являются Вами documenation. Таким образом, если Вы не знаете то, что Вы тестируете, тогда Вы не знаете то, что Вы хотите свое приложение, собирается сделать?
можно начаться с "Историями", которые могли бы быть чем-то как
"Пользователи, может Получить список Вопросов"
Тогда, поскольку Вы начинаете писать код для решения модульных тестов. Для решения вышеупомянутого, Вам будут нужны, по крайней мере, Пользователь и класс вопроса. Таким образом можно начать думать о полях:
"Пользовательский Класс Имеет Имя Адрес DOB TelNo Заблокированные Поля"
и т.д. Надежда это помогает.
Лукавый
Я не пишу фактические модульные тесты сначала, но я действительно делаю тестовую матрицу, прежде чем я начну кодировать список всех возможных сценариев, которые должны будут быть протестированы. Я также составляю список случаев, которые должны будут быть протестированы, когда изменение внесено в любую часть программы как часть регрессионного тестирования, которое покроет большинство основных сценариев в приложении в дополнение к полностью тестированию бита кода, который изменился.
Я не уверен, но из Вашего описания я обнаруживаю это могло бы быть недоразумение на том, что сначала на самом деле означает тест. Это делает не средний, который Вы пишете весь Ваши тесты сначала. Это действительно означает, что у Вас есть очень трудный цикл [1 110]
- , пишут, что единственный, минимальный тест
- делает тестовую передачу путем записи, что минимальное производство кодирует необходимый
- , пишут следующий тест, который перестанет работать
- , делают всю существующую тестовую передачу путем изменения существующего производственного кода самым простым способом
- , осуществляют рефакторинг код (и тест и производство!) так, чтобы это не содержало дублирование и было выразительно
- , продолжают 3. пока Вы не можете думать о другом разумном тесте
, Один цикл (3-5) обычно просто занимает несколько минут. Используя эту технику, Вы на самом деле развиваетесь дизайн, в то время как Вы пишете свои тесты и производственный код параллельно. Нет большого честного дизайна, включенного вообще.
По вопросу о нем являющийся "необходимым" - нет, это, очевидно, не. Были неисчислимые проекты, успешные, не делая TDD. Но существуют некоторые убедительные доказательства там, что использование TDD обычно приводит к значительно более высокому качеству, часто без негативного воздействия на производительность. И это интересно, также!
, О, и относительно него не ощущение себя "естественным", это - просто вопрос того, к чему Вы привыкли. Я знаю людей, которые вполне увлекаются получением зеленой панели (типичные xUnit расписываются "за всю тестовую передачу"), каждые несколько минут.
Прежде, в течение и после. Прежде часть спецификации, контракта, определение работы Во время - когда особые случаи, неправильные данные, исключения раскрыты при реализации. После обслуживание, эволюция, изменение, новые требования.
Лично, я полагаю, что модульные тесты теряют большую свою эффективность если не сделанный прежде, чем записать код.
возраст старая проблема с тестированием состоит в том, что, неважно, как трудно мы думаем об этом, мы никогда не будем придумывать каждый возможно сценарий для записи теста для покрытия.
само Очевидно поблочное тестирование не предотвращает это полностью, как он строгое тестирование, смотря только на одну единицу кода, не покрывающего взаимодействия между этим кодом и всем остальным, но это обеспечивает хорошую основу для записи чистого кода во-первых, который должен, по крайней мере, ограничить возможности для проблем взаимодействия между модулями. Я всегда работал к принципу хранения кода, столь простого, как это возможно может быть - заражают, я полагаю, что это - один из ключевых принципов TDD.
Настолько начинающийся с тестом, который в основном говорит, можно создать класс этого типа и создать его, в теории, пишущий тест для каждой строки кода или по крайней мере покрыв каждый маршрут через конкретную часть кода. Разработка, когда Вы идете! Очевидно, на основе грубо-честного дизайна, произведенного первоначально, чтобы дать Вам платформу для работы к.
, Как Вы говорите, это очень неестественно для запуска с и может походить на пустую трату времени, но я видел меня на собственном опыте, что это окупается в конечном счете, когда статистика дефектов проникает и показывает модули, которые были полностью записаны с помощью TDD, имеют намного более низкие дефекты со временем, чем другие.
Запись тестов сначала определяет, как Ваш код будет похож - т.е. это имеет тенденцию делать Ваш код более модульным и тестируемым, таким образом, Вы не создаете "чрезмерное увеличение размера" методы с очень сложной и перекрывающейся функциональностью. Это также помогает изолировать всю базовую функциональность в отдельных методах для более легкого тестирования.
Я думаю, пишущий, что тест сначала помогает определить то, что должен на самом деле сделать код. У людей слишком многих раз нет хорошего определения того, что код, как предполагается, делает или как он должен работать. Они просто начинают писать и составляют его, как они продвигаются. Создание теста сначала заставляет Вас сфокусироваться на том, что сделает код.
Я программировал в течение 20 лет, и я фактически никогда не писал строку кода, что я не работал на некотором модульном тесте - Честно я знаю, что люди делают все это время, но как кто-то может поставить строку кода, который не имел некоторого тестового прогона на нем, вне меня.
Часто, если там не существует никакая среда тестирования, я просто пишу основное () в каждый класс, который я пишу. Это добавляет немного хлама к Вашему приложению, но кто-то может всегда удалять его (или комментировать его), если они хотят, я предполагаю. Мне действительно жаль, что не было только теста () метод в Вашем классе, который автоматически скомпилирует для сборок конечных версий - я люблю свой метод тестирования, находящийся в том же файле как мой код...
, Таким образом, я сделал и Разработку через тестирование и Протестированную разработку. Я могу сказать Вам, что TDD может действительно помочь, когда Вы - начинающий программист. Это помогает Вам учиться просматривать свой код, "Снаружи" которого один из самых важных уроков, которые может извлечь программист.
TDD также помогает Вам начать, когда Вы застреваете. Можно просто некоторые очень писать мелко часть, что Вы знаете, что Ваш код должен сделать, затем выполнить ее и зафиксировать ее - это становится захватывающим.
, С другой стороны, когда Вы добавляете к существующему коду и знаете в значительной степени точно, что Вы хотите, это - жеребьевка. Ваш "Другой код" часто тестирует Ваш новый код на месте. Все еще необходимо быть уверены, что Вы тестируете каждый путь, но Вы получаете хорошее покрытие только путем запущения тестов от фронтенда (за исключением динамических языков - для тех у Вас действительно должны быть модульные тесты на все, неважно, что).
Между прочим, когда я был на довольно большом проекте Ruby/направляющих, у нас был очень высокий % тестового покрытия. Мы осуществили рефакторинг главный, центральный образцовый класс в два класса. Нам потребовались бы два дня, но со всеми тестами мы должны были осуществить рефакторинг его, закончился ближе к двум неделям. Тесты не абсолютно свободны.
Директивы являются предложением о том, как Вы могли сделать вещи улучшить общее качество или производительность или даже оба из конечного продукта. Они не находятся никакими способами законы, которым повинуются меньше, Вы сражены во флэш-памяти богом надлежащей практики кодирования.
Вот мой компромисс на взятии, и я нашел его довольно полезным и продуктивным.
Обычно самая твердая часть для разбираний требования и прямо позади него удобство использования класса, API, пакета... Тогда фактическая реализация.
- Запись Ваши интерфейсы (они изменят, но будут иметь большое значение в знании , ЧТО должен быть сделан)
- Запись простая программа для использования интерфейсов (их глупое основное). Это имеет большое значение в определении , КАК это будет используемым (вернитесь к 1 как часто по мере необходимости)
- Тесты записи в интерфейсе (Бит я интегрировался от TDD, снова вернитесь к 1 как часто по мере необходимости)
- , пишут фактический код позади интерфейсов
- тесты записи на классах и фактическая реализация, используют инструмент покрытия, чтобы удостовериться, что Вы не забываете weid пути выполнения
Так, да я тесты записи прежде, чем кодировать, но никогда прежде чем я выяснил что потребности быть сделанным с определенным уровнем деталей. Они - обычно тесты высокого уровня и только рассматривают целое как черный квадрат. Обычно будет оставаться как интеграционные тесты и не изменится очень, как только интерфейсы стабилизировались.
Тогда я пишу набор тестов (модульные тесты) на реализации позади него, они будут намного более подробными и будут часто изменяться, поскольку реализация развивается, поскольку это добирается, оптимизировал и расширился.
это строго говоря TDD? Экстремальное значение? Гибкий...? безотносительно...? Я не знаю, и откровенно я не забочусь. Это работает на [1 115] меня . Я корректирую его, когда потребности идут и поскольку мое понимание практики разработки программного обеспечения развивается.
мои 2 цента
Я запускаю с того, как я хотел бы назвать свою "единицу" и заставить ее скомпилировать. как:
picker = Pick.new
item=picker.pick('a')
assert item
тогда я создаю
class Pick
def pick(something)
return nil
end
end
тогда, я продолжаю использовать Выбор в своем "тестовом" случае, таким образом, я видел, как я хотел бы, чтобы он был назван и как я буду рассматривать различные виды поведения. Каждый раз, когда я понимаю, что мог испытать затруднения на некоторых границах или некоторой ошибке/исключении, я пытаюсь заставить его запускать и получать новый тестовый сценарий.
Так, короче говоря. Да. Тест выполнения отношения прежде намного выше, чем не выполнение его.
Я склонен писать им, поскольку я пишу свой код. Самое большее я запишу тесты для того, если класс/модуль будет существовать, прежде чем я запишу его.
я не планирую достаточно далеко вперед в так большом количестве деталей записать тест ранее, чем код, который они собираются протестировать.
я не знаю, является ли это дефектом в моих взглядах или или просто TIMTOWTDI метода.
Не всегда, но я нахожу, что действительно помогает, когда я делаю.
У меня есть ведущие группы разработчиков в течение прошлых 6-7 лет. Что я могу сказать, наверняка то, что как разработчик и разработчики, с которыми я работал, это имеет феноменальное значение в качестве кода, если мы знаем, где наш код вписывается в большое изображение.
Разработка через тестирование (TDD) помогает нам ответить "Что?" прежде чем мы ответим "Как?" и это имеет большое значение.
я понимаю, почему могут быть предчувствия о не следовании за ним в типе PoC работы разработки/архитектора. И Вы правы, что не может иметь полного смысла следовать за этим процессом. В то же время я хотел бы подчеркнуть, что TDD является процессом, который падает в Этапе разработки (я знаю, что это звучит устаревшим, но Вы понимаете:), когда низкоуровневая спецификация ясны.
TDD не о тестах, но как тесты управляют Вашим кодом. Так в основном Вы пишете тесты, чтобы позволить архитектуре развиться естественно (и не забывайте осуществлять рефакторинг!!! иначе Вы не вытащите много преимущества из него). То, что у Вас есть арсенал регрессионных тестов, и исполняемая документация впоследствии является хорошим sideeffect, но не главной причиной позади TDD.
, Таким образом, мой голос: Протестируйте сначала
пз: И не, который не означает, что Вы не должны планировать свою архитектуру прежде, но что Вы могли бы заново продумать ее, если тесты говорят Вам делать так!!!!
Были исследования , которые показывают, что модульные тесты, записанные после кода, были записаны, лучшие тесты. Протест, хотя то, что люди не склонны писать им после события. Таким образом, TDD является хорошим компромиссом как, по крайней мере, тесты записаны.
Поэтому, если Вы тесты записи после записи кода, хорошего для Вас, я предложил бы, Вы упорно продолжаете его.
я склонен находить, что я делаю смесь. Чем больше я понимаю требования, тем больше тестов я могу записать впереди. Когда требования - или мое понимание проблемы - слабы, я склоняюсь к тестам записи впоследствии.