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

Question

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

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

Answer 1

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

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

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

EDIT:

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

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

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

Answer 2

Перед проверкой кода в.

Answer 3

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

Answer 4

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

"Проверяй рано, проверяй часто и проверяй снова, когда думаешь, что все готово"

Answer 5

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

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

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

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

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

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

Answer 6

Здесь много хороших ответов!

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

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

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

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

• Протестируйте каждый модуль с той же стратегией, что и выше.

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

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

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

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

Answer 7

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

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

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

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

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

Answer 8

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

Answer 9

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

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

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

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

Answer 10

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

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

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