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

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

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

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

EDIT:

Я подумал, что мне, вероятно, следует расширить это, это мой основной "working process"...

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

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

Перед тем, как проверить код.

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

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

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

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

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

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

Хороший ключ, чтобы помнить это

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

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

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

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

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

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

Наверное, я бы сказал: "Test often."

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

• чтобы выразить требования для каждого нового модуля кода (сразу после написания интерфейса, но до написания реализации)
• каждый раз, когда я думаю "it had better ... by the time I'm done"
• когда что-то ломается, чтобы количественно определить ошибку и доказать, что я ее исправил
• когда я пишу код, который явно выделяет или освобождает память-я ненавижу охоту за утечками памяти...

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

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

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

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

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

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

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

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

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

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

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

Много отличных ответов здесь!

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

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

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

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

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

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

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

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

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