2012-02-19 2 views
4

Я нахожусь в проекте, где мы не делаем TDD, потому что наши боссы и клиент очень «старомодные» люди. Поскольку я не могу делать дизайн через TDD, но я чувствую страх перед изменениями, я хотел бы написать модульные тесты для собственной безопасности. Но как будет проходить этот единичный тест? Должен ли я писать тест для каждой спецификации метода для проверки того, что они делают то, что, как предполагается, они делают? Должен ли я тестировать каждую новую функциональность, такую ​​как TDD, но без дизайна? У меня в голове беспорядок.Можно выполнить единичный тест без TDD?

Заранее спасибо.

ответ

6

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

Мы, как правило, не делать хардкор TDD, тем не менее, блок тестового покрытия составляет от несуществующего до умеренного в зависимости от проекта, и становится все более ценным, как идея оседает в.

Для общих указателей, я бы сказать следующее являются ключевыми приоритетами для вас прямо сейчас:

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

Да. TDD - еще одна технология разработки программного обеспечения, которая используется для интенсивного тестирования модулей. Единичное тестирование как процесс само по себе без TDD. Не говоря уже о том, что иногда даже TDD нельзя делать, но вы пишете тесты (подумайте о старых системах/тестировании непроверенных кодов).

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

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

  • тест, что ваш код does, а не что не
  • , если у вас есть определенное требование, есть тест covering it
  • тест single feature во время
  • фокуса на public contract, пропустить отдельные биты

Кроме того, чтение несколько top votedunit testing вопросов могут дать вам некоторые идеи о том, почему вы выиграете от тестирования, независимо от того, с использованием TDD или нет.

1

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

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

Смежные вопросы