Как написать хорошие тесты единиц?

Ответ 1

Важным моментом (который я не понимал в начале) является то, что Unit Testing является методом тестирования, который может использоваться сам по себе, без необходимости применения полной методологии Test Driven.

Например, у вас есть устаревшее приложение, которое вы хотите улучшить, добавляя модульные тесты в проблемные области или вы хотите найти ошибки в существующем приложении. Теперь вы пишете unit test, чтобы открыть код проблемы, а затем исправить. Они основаны на результатах тестирования, но могут полностью соответствовать вашему текущему (не TDD) процессу разработки.

Две полезные слова:

Test Driven Development в Microsoft.NET

Очень руки смотрят на Test Driven development, следуя оригинальной книге TDD Кент Беккс.

Прагматическое тестирование модуля с помощью С# и nUnit

Доходит до того, что такое модульное тестирование, и как его применять.

В ответ на ваши вопросы:

• A Unit test, на практике это единственный метод в классе, который содержит достаточно кода для проверки одного аспекта/поведения вашего приложения. Поэтому у вас часто будет много очень простых модульных тестов, каждый из которых тестирует небольшую часть вашего кода приложения. Например, в nUnit вы создаете класс TestFixture, который содержит любое количество методов тестирования. Ключевым моментом является то, что тесты "проверяют единицу" вашего кода, т.е. Наименьшее (разумное) устройство, насколько это возможно. Вы не тестируете базовый API, который вы используете, просто код, который вы написали.

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

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

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

Ответ 2

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

• Эффективно работает с устаревшим кодом - Michael Feathers. Насколько я знаю, это единственная книга, которая должна адекватно решить тему превращения существующего кода, который не был предназначен для проверки в тестируемый код. Написано как более справочное руководство, оно разбито на три раздела: Обзор инструментов и методов. Серия тематических руководств по общим дорожным блокам в устаревшем коде. Набор специальных методов нарушения зависимости, на которые ссылается всю оставшуюся часть книги.
• Agile Principles, Patterns and Practices - Robert C. Martin. Примеры в java. В С# есть примеры с примерами. Оба легко адаптироваться к С++
• Чистый код: руководство по гибкому программному мастерству - Роберт К. Мартин - Мартин описывает это как приквел к своим книгам APPP, и я бы согласился. Эта книга посвящена профессионализму и самодисциплине, двум существенным качествам любого серьезного разработчика программного обеспечения.

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

Ответ 3

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

• Да, есть рамки. Пара самых известных:
  Boost Unit Test Framework
  CPPUNit

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

• Тестирование модулей должно быть достаточным для обеспечения работы кода. Если (например) у вас есть частная функция, которая используется внутри, вам обычно не нужно ее проверять напрямую. Вместо этого вы проверяете все, что предоставляет публичный интерфейс. Пока это работает правильно, это не бизнес внешнего мира, как он выполняет свою работу. Конечно, в некоторых случаях легче тестировать маленькие кусочки, и когда это так, это совершенно законно, но в конечном итоге вы заботитесь о видимом интерфейсе, а не о внутренних. Разумеется, весь внешний интерфейс должен быть реализован, а тестовые примеры обычно выбираются для реализации путей через код. Опять же, нет ничего массового различия в модульных тестах по сравнению с другими видами. Это в основном просто более систематический способ применения обычных методов тестирования.

Ответ 4

В .NET я настоятельно рекомендую Roy Osherove "Искусство модульного тестирования", он очень всеобъемлющий и полный хороших советов.

Ответ 5

Я не могу ответить на ваш вопрос для Visual Studio 2008, но я знаю, что Netbeans содержит несколько интегрированных инструментов для вас использовать.

• Покрытие кода 2 позволяет вам видеть, какие пути были проверены, и сколько кода на самом деле покрывается модульными тестами.
• Он поддерживает встроенные тесты.

Что касается качества тестов, я немного заимствую из "" Прагматическое тестирование модуля в Java с помощью JUnit" Эндрю Ханта и Дэвид Томас:

Тестирование модулей должно проверяться на BICEP: B, I обратные отношения, C ross-проверка, E условия rror и P наилучших показателей.

Также качество тестов определяется A-TRIP: A utomatic, T horough, R, возможно, I независимый и P rofessional.

Ответ 6

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

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

Сначала возьмите копию NUnit. Он бесплатный, прост в установке и удобен в работе. Если вам нужна какая-либо документация, проверьте Прагматическое тестирование модуля в С# с помощью NUnit.

Затем перейдите в http://www.testdriven.net/ и получите копию TestDriven.net. Он устанавливается в Visual Studio 2008 и дает вам доступ по правому клику к широкому спектру инструментов тестирования, включая возможность запуска тестов NUnit против файла, каталога или проекта (как правило, тесты записываются в отдельный проект). Вы также можете запускать тесты с отладкой или, что самое интересное, запускать все тесты против копии NCover. NCover покажет вам, какой именно код используется, чтобы вы могли выяснить, где вам нужно улучшить покрытие для тестирования. TestDriven.net стоит 170 долларов за профессиональную лицензию, но если вы похожи на меня, он очень быстро станет неотъемлемым инструментом в вашем наборе инструментов. Во всяком случае, я считаю, что это отличная профессиональная инвестиция.

Удачи!

Ответ 7

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

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

Что такое Unit Test? Это полный перечень тестовых примеров, которые следует проанализировать?

A Unit Test - это фрагмент кода, который запрашивает "блок" вашего кода для выполнения операции, а затем проверяет, что операция действительно выполнена, и результат будет таким, как ожидалось. Если результат неверен, он вызывает/регистрирует ошибку.

Так что давайте скажем, что у меня есть класс, называемый "Комплексные числа" с некоторыми методами в он (позволяет говорить о нахождении сопряженных, перегруженный оператор присваивания и перегруженный оператор умножения. Какими должны быть типичные тестовые примеры для такой класс? Есть ли какая-либо методология для выбора тестовых случаев?

В идеале вы проверили бы весь код.

• когда вы создаете экземпляр класс, он создается с правильным значения по умолчанию

• когда вы попросите его найти конъюгатов, он находит правильное (также проверяют пограничные случаи, например, сопряжено для нуля)

• когда вы назначаете значение, значение правильно и правильно отображается

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

Существуют ли какие-либо рамки, которые могут создайте для меня модульные тесты, или я должен написать собственный класс для тестов?

См. CppUnit

Я вижу вариант "Тест" в Visual Studio 2008, но он никогда не работал.

Не уверен в этом. Я не использовал VS 2008, но он может быть доступен только для .NET.

Каковы критерии для тестов единиц? Должна быть Unit Test для каждого и каждая функция в классе? Имеет ли это иметь смысл иметь Единичные тесты для каждого и каждый класс?

Да, да. Хотя это очень много кода для написания (и поддержания с каждым изменением), цена стоит платить за большие проекты: он гарантирует, что ваши изменения в базе кода будут делать то, что вы хотите, и ничего больше.

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

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

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

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

Для дальнейшего чтения/документации просмотрите "инъекции зависимостей" и заглушки методов, используемые в модульном тестировании и TDD.

Ответ 8

Здесь что-то о том, когда не писать модульные тесты (т.е. когда это жизнеспособно и даже предпочтительнее пропустить модульное тестирование): Следует ли проверять внутреннюю реализацию или тестировать только публичное поведение?

Короткий ответ:

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

Ответ 9

Купить книгу "xUnit Test Patterns: Рефакторинг тестового кода". Это очень хорошо. Он охватывает высокоуровневые стратегические решения, а также тестовые шаблоны низкого уровня.

Ответ 10

В настоящее время Test Driven Development - это подход для управления большими программными проектами с легкостью.

TDD построен на модульных тестах, но они разные. Вам не нужно использовать TDD для использования модульных тестов. Мое личное предпочтение - сначала написать тест, но я не чувствую, что делаю всю TDD.

Что такое Unit Test?

A Unit Test - это немного кода, который проверяет поведение одного устройства. Как определяется одна единица между людьми. Но в целом они:

• Быстрый запуск
• Независимые друг от друга
• Проверьте только небольшую часть (блок;) базы кода.
• Двоичный результат. То есть он проходит или терпит неудачу.
• Необходимо проверить только один результат устройства (для каждого результата создайте другой unit test)
• Повторяющиеся

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

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

Должно ли существовать Unit Test для каждой функции в классе?

У вас есть несколько различных лагерей в этом - 100% сказали бы "да". Каждый метод должен быть протестирован, и вы должны иметь 100% охват кода. Другая крайность заключается в том, что модульные тесты должны охватывать только те области, в которых вы столкнулись с ошибками или вы ожидаете найти ошибки. Средняя земля (и позиция, которую я беру) - это блок, который проверяет все, что не "слишком просто сломать". Setters/getters и все, что просто вызывает один другой метод. Я нацелен на покрытие 80% кода и низкий CRAP фактор (так что низкий шанс я был непослушен и решил не тестировать что-то, что было "слишком сложно проверить".

Книга, которая помогла мне "получить" модульные тесты JUnit in Action. Извините, я много не делаю в мире С++, поэтому я не могу предложить альтернативу на С++.