Когда / как часто я должен проверять?

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

Мой вопрос в том, какой ритм вы хотели бы использовать, работая над большими проектами, и где подходит тестирование.

22.08.2008 17:54:10
12 ОТВЕТОВ
РЕШЕНИЕ

Хорошо, если вы хотите следовать за парнями из TDD, прежде чем начинать кодировать ;)

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

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

РЕДАКТИРОВАТЬ:

Я подумал, что мне, вероятно, стоит остановиться на этом, это мой основной «рабочий процесс» ...

  1. Планируйте то, что я хочу от кода, возможный дизайн объекта, что угодно.
  2. Создайте мой первый класс, добавьте огромный комментарий к началу, описывающий мое «видение» класса.
  3. Описать основные сценарии тестирования. В основном они станут модульными тестами.
  4. Создайте мой первый метод. Также напишите короткий комментарий, объясняющий, как он должен работать.
  5. Напишите автоматизированный тест, чтобы увидеть, соответствует ли он ожиданиям.
  6. Повторите шаги 4-6 для каждого метода (обратите внимание, что автоматические тесты находятся в огромном списке, который выполняется на F5).
  7. Затем я создаю несколько мощных тестов для эмуляции класса в рабочей среде, очевидно, исправляя любые проблемы.
  8. Если после этого обнаружатся какие-либо новые ошибки, я вернусь и напишу новый тест, убедитесь, что он не пройден (это также служит доказательством концепции ошибки), а затем исправлю ее.

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

6
22.08.2008 18:09:25

Прежде чем проверить код в.

2
22.08.2008 17:56:17

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

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

0
22.08.2008 17:56:38

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

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

Я думаю, я бы сказал: «Тестируйте часто».

0
22.08.2008 18:03:18

Я только недавно добавил модульное тестирование в свой обычный рабочий процесс, но я пишу модульные тесты:

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

Я запускаю тесты на большинстве сборок и всегда перед запуском кода.

0
22.08.2008 18:03:22

Начните с модульного тестирования. В частности, ознакомьтесь с TDD, Test Driven Development. Концепция TDD заключается в том, что вы сначала пишете модульные тесты, а затем пишете свой код. Если тест не пройден, вы возвращаетесь и заново работаете со своим кодом. Если это проходит, вы переходите к следующему.

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

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

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

0
22.08.2008 18:05:21

Сначала и часто. Если я создаю какую-то новую функциональность для системы, я постараюсь сначала определить интерфейсы, а затем написать модульные тесты для этих интерфейсов. Чтобы выяснить, какие тесты для написания, рассмотрите API интерфейса и предоставляемые им функциональные возможности, достаньте ручку и бумагу и подумайте немного о возможных условиях ошибки или способах доказать, что она выполняет правильную работу. Если это слишком сложно, вероятно, ваш API недостаточно хорош. Что касается тестов, посмотрите, не можете ли вы написать «интеграционные» тесты, которые тестируют более одного конкретного объекта и сохраняют их как «модульный» тест.

Затем создайте реализацию интерфейса по умолчанию (которая ничего не делает, возвращает мусорные значения, но не генерирует исключения), подключите ее к тестам, чтобы убедиться, что тесты не пройдены (это тесты, которые ваши тесты работают! :)). Затем напишите в функциональности и перезапустите тесты. Этот механизм не идеален, но он будет охватывать множество простых ошибок кодирования и даст вам возможность запустить новую функцию без необходимости подключать ее ко всему приложению.

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

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

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

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

1
22.08.2008 18:09:38

Хороший ключ для запоминания

«Тестируйте рано, тестируйте часто и тестируйте снова, когда вы думаете, что вы сделали»

1
22.08.2008 18:46:55

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

0
22.08.2008 19:00:10

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

Красный : напишите свой тест, чтобы он не прошел. Таким образом, вы знаете, что тест утверждает против правильной переменной.

Зеленый : Сделайте свой новый тест максимально простым. Если это означает жесткое программирование, это нормально. Это отлично подходит для тех, кто просто хочет, чтобы что-то сработало прямо сейчас.

Рефакторинг : Теперь, когда ваш тест пройден, вы можете вернуться и изменить свой код с уверенностью. Ваше новое изменение сломало ваш тест? Отлично, ваше изменение имело значение, которого вы не осознавали, теперь ваш тест говорит вам.

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

0
10.09.2008 15:42:43

Когда тестировать? Когда важно, чтобы код работал правильно!

1
20.09.2008 05:22:17

Здесь много отличных ответов!

Я пытаюсь проверить на самом низком уровне, который имеет смысл:

  • Если одно вычисление или условие сложно или сложно, добавьте тестовый код во время написания и убедитесь, что каждый фрагмент работает. Закомментируйте тестовый код, когда закончите, но оставьте его там, чтобы документировать, как вы тестировали алгоритм.

  • Проверьте каждую функцию.

    • Упражнение каждую ветвь хотя бы один раз.
    • Выполните граничные условия - входные значения, при которых код меняет свое поведение - чтобы отловить «одну ошибку».
    • Проверьте различные комбинации действительных и недействительных входных данных.
    • Ищите ситуации, которые могут нарушить код, и протестируйте их.
  • Протестируйте каждый модуль с той же стратегией, что и выше.

  • Проверьте тело кода в целом, чтобы убедиться, что компоненты взаимодействуют должным образом. Если вы усердно относились к тестированию более низкого уровня, это, по сути, «проверка достоверности», чтобы убедиться, что ничего не сломалось во время сборки.

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

В общем, чем раньше вы столкнетесь с ошибкой, тем легче ее выделить, идентифицировать и исправить - и тем больше времени вы потратите на создание, а не на погоню за хвостом. *

** Я знаю -1 для бесплатной ссылки на указатель буфера! *

0
29.10.2008 01:14:42