TDD по сравнению с [закрытым] Поблочным тестированием

FileMon является свободным одиноким инструментом, который может обнаружить все виды доступа к файлу. Можно отфильтровать любого нежелательного. Это не показывает Вам данные, которые на самом деле изменились все же.

117
задан 9 revs 14 January 2010 в 15:02
поделиться

17 ответов

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

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

76
ответ дан 24 November 2019 в 02:08
поделиться

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

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

Я обычно делаю автоматические Приемочные тесты не подлежит обсуждению, но позволяет разработчикам использовать TDD по своему усмотрению. У меня есть опытные TDDers, которые обучают / наставляют остальных и «доказывают» полезность на примере в течение многих месяцев.

1
ответ дан 24 November 2019 в 02:08
поделиться

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

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

Этот подход много раз работал у меня в прошлом.

2
ответ дан 24 November 2019 в 02:08
поделиться

Нет сомнений в том, что тестирование (сначала, во время или даже после) спасет ваш бекон и повысит вашу продуктивность и уверенность в себе. Рекомендую взять на вооружение!

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

4
ответ дан 24 November 2019 в 02:08
поделиться

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

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

Что касается управления версиями, мне нравится использовать « ветвей разработки » с политикой модульного тестирования (т.е. код компилируется и сборки, все модульные тесты проходят). Когда функции готовы, они публикуются из веток разработки в основной поток. Другими словами, магистральная ветвь - это "

6
ответ дан 24 November 2019 в 02:08
поделиться

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

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

  • сообщается об ошибке
  • создать тестовый класс JUnit, если необходимо
  • добавить тест, который воспроизводит ошибку
  • исправить ваш код
  • запустить тест, чтобы показать, что текущий код не воспроизводит ошибку

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

2
ответ дан 24 November 2019 в 02:08
поделиться

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

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

Кроме того, BDD также может представлять интерес

3
ответ дан 24 November 2019 в 02:08
поделиться

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

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

2
ответ дан 24 November 2019 в 02:08
поделиться

Вы можете найти некоторую тягу, показав один или два примера, где TDD приводит к написанию меньшего количества кода - потому что вы пишете только код, необходимый для прохождения теста, искушение позолочить или задействовать в ЯГНИ легче устоять. Код, который вы не пишете, не требует поддержки, рефакторинга и т. Д., Так что это «реальная экономия», которая может помочь продать концепцию TDD.

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

3
ответ дан 24 November 2019 в 02:08
поделиться

Что ж, если вы сначала не пишете тесты, это не "Test Driven", это просто тестирование. Он имеет преимущества сам по себе, и если у вас уже есть база кода, добавление тестов для него, безусловно, полезно, даже если это не TDD, а просто тестирование.

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

Я бы хотел обучить команду игрушечным проектам, подобным этим (см. Coding Dojo , Katas) с использованием TDD (если бы вы смогли привлечь к участию в таком семинаре опытных программистов TDD, было бы еще лучше). Когда они увидят преимущества, они будут использовать TDD для реального проекта. Но пока не заставляйте их, они не видят выигранной выгоды ».

3
ответ дан 24 November 2019 в 02:08
поделиться

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

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

3
ответ дан 24 November 2019 в 02:08
поделиться

Это то, с чем ваша команда должна будет добиться собственных успехов, прежде чем они начнут в это верить. Я буду разглагольствовать о моем прозрении nUnit всем, кому небезразлично:

Около 5 лет назад я открыл для себя nUnit, когда работал над проектом. Мы почти завершили V1.0, и я создал несколько тестов, чтобы опробовать этот новый инструмент. У нас было много ошибок (очевидно!), Потому что мы были новой командой, у нас были сжатые сроки, большие ожидания (звучит знакомо?) И т. Д. В любом случае мы получили 1.0 и начали с 1.1. Мы немного переделали команду, и мне назначили двух разработчиков. Я провел для них 1-часовую демонстрацию и сказал, что все, что мы написали, должно иметь тестовый пример. Мы постоянно отставали от остальной команды в течение цикла разработки 1.1, потому что мы писали больше кода, модульных тестов. В итоге мы работали больше, но здесь ' Результат - когда мы наконец приступили к тестированию, в нашем коде было ровно 0 ошибок. Мы помогли всем остальным отлаживать и исправлять их ошибки. На вскрытии, когда обнаружился счетчик ошибок, он привлек внимание ВСЕХ.

Я не настолько глуп, чтобы думать, что вы можете проверить свой путь к успеху, но я искренне верю, когда дело доходит до модульных тестов. Проект принял nUnit и вскоре распространился на все проекты .Net в компании в результате одного успеха. Общий период времени для нашего выпуска V1.1 составил 9 недель разработки, так что это определенно НЕ было мгновенным успехом. Но в долгосрочной перспективе это оказалось успешным для нашего проекта и компании, для которой мы создавали решения.

Внимание.

Я не настолько глуп, чтобы думать, что вы можете проверить свой путь к успеху, но я искренне верю, когда дело касается модульных тестов. Проект принял nUnit и вскоре распространился на все проекты .Net в компании в результате одного успеха. Общий период времени для нашего выпуска V1.1 составил 9 недель разработки, так что это определенно НЕ было мгновенным успехом. Но в долгосрочной перспективе это оказалось успешным для нашего проекта и компании, для которой мы создавали решения.

внимание.

Я не настолько глуп, чтобы думать, что вы можете проверить свой путь к успеху, но я искренне верю, что касается модульных тестов. Проект принял nUnit и вскоре распространился на все проекты .Net в компании в результате одного успеха. Общий период времени для нашего выпуска V1.1 составил 9 недель разработки, так что это определенно НЕ было мгновенным успехом. Но в долгосрочной перспективе это оказалось успешным для нашего проекта и компании, для которой мы создавали решения.

4
ответ дан 24 November 2019 в 02:08
поделиться

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

Также помните, что нет ничего плохого в написании тестов для проверки кода вместо написания кода для удовлетворения тестов. Если ваша команда не хочет идти по пути TDD, не навязывайте им это.

9
ответ дан 24 November 2019 в 02:08
поделиться

TDD - это дизайн! Так что, если вы его используете, у вас обязательно будет тестируемый дизайн вашего кода, что упростит написание тестов. Если вы пишете тесты после написания кода, они все еще ценны , но ИМХО вы будете зря тратить время, так как у вас, вероятно, не будет тестируемого дизайна.

Я могу дать вам одно предложение, чтобы попытаться убедить ваша команда по внедрению TDD использует некоторые методы, описанные в Бесстрашные перемены: шаблоны для внедрения новых идей Мэри Линн Маннс и Линда Райзинг .

12
ответ дан 24 November 2019 в 02:08
поделиться

По моему скромному мнению, лучше иметь 50% тестового покрытия с "сначала код, потом тестирование" и 100% завершенную библиотеку, чем 100% тестовое покрытие и 50% завершенную библиотеку с TDD . Через некоторое время ваши коллеги-разработчики, надеюсь, сочтут интересным и познавательным писать тесты для всего общедоступного кода, который они пишут, так что TDD незаметно проникнет в их рутину разработки.

16
ответ дан 24 November 2019 в 02:08
поделиться

Я только что прочитал это в календаре: «Каждое правило, выполняемое до предела, становится смешным или даже опасным». Поэтому я предлагаю не относиться к этому религиозно. Каждый член вашей команды должен найти баланс между тем, что он считает «правильным», когда дело касается тестирования. Таким образом, каждый член вашей команды будет наиболее продуктивным (вместо того, чтобы, скажем, думать «зачем мне писать этот строгий тест ??»).

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

12
ответ дан 24 November 2019 в 02:08
поделиться

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

Я думаю, что хороший прагматичный способ вовлечь команду в TDD - это предоставить альтернативный метод «тестирования- во время разработки »в переходный период или, возможно, в долгосрочной перспективе. Их следует поощрять к использованию TDD участков кода, которые кажутся им естественными. Однако в разделах кода, которые кажутся сложными для подхода к тестированию, или при использовании объектов, которые предопределены неагильным процессом A&D, разработчикам может быть предоставлена ​​возможность написать небольшой фрагмент кода, а затем написать тесты, чтобы охватить это. код и повторяя этот процесс.

27
ответ дан 24 November 2019 в 02:08
поделиться
Другие вопросы по тегам:

Похожие вопросы: