Руководство по тестированию устройств

Ответ 1

Я бы рекомендовал книгу Кента Бекка о TDD.

Кроме того, вам нужно перейти на сайт Мартина Фаулера. У него также есть много хорошей информации о тестировании.

Мы довольно большие на TDD, поэтому я отвечу на вопросы в этом свете.

Должны ли тесты быть в том же проекте, что и логика приложения?

Обычно мы сохраняем наши тесты в одном и том же решении, но мы прерываем тесты в отдельные DLL-проекты/Проекты, которые отражают тестируемые DLL-проекты и проекты, но сохраняют пространства имен с тестами, находящимися в подпространстве имен. Пример: Common/Common.Tests

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

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

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

Мне нравится подчеркивать, что поведение - это то, что тестируется, поэтому я обычно называю тестовые классы после SUT. Например, если бы у меня был класс User, я бы назвал тестовый класс следующим:

public class UserBehavior

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

public void ShouldBeAbleToSetUserFirstName()

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

Должны ли быть проверены частные, защищенные и внутренние методы или только те, которые общедоступны?

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

Должны ли разделяться тесты на единицу и интеграцию?

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

Есть ли веская причина не иметь 100% -ный охват тестирования?

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

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

Ответ 2

Это хороший вопрос. Мы выросли сами по себе, и я подозреваю, что лучший способ - это просто. Там немного "Это зависит...".

Мы проводим тесты в том же проекте, в пространстве под-имен под названием "UnitTes"

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

Классы называются как класс логики, который они тестируют, методы называются для сценария, который они тестируют.

Мы пишем только тесты для общедоступных и внутренних методов (тесты находятся в одном проекте) и нацелены на покрытие 95% класса.

Я предпочитаю не различать "единица" и "intergation". Довольно много времени будет потрачено, пытаясь выяснить, что это... сумка, которая! Тест - это тест.

100% слишком сложно достичь все время. Мы нацелены на 95%. Там также уменьшается отдача от того, сколько времени потребуется, чтобы получить последние 5% и то, что он действительно поймает.

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

Я с нетерпением жду, что другие скажут об этом!

Ответ 3

Ответ Джоша на правильном пути - только одна точка разъяснения:

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

Не пересекайте лучи. Плохие вещи произойдут, если вы это сделаете.

Ответ 4

Я настоятельно рекомендую вам прочитать Test Driven Development: на примере и Разработка, основанная на испытаниях: практическое руководство Это слишком много вопросов для отдельной темы

Ответ 5

В порядке:

• Нет, обычно лучше включить их в отдельный проект; если вы не хотите запускать диагностику во время выполнения.
• Идеал - это 100% -ый охват кода, что означает каждую строку кода в каждой процедуре в каждом классе.
• Я иду с ClassnameTest, ClassnameTest.MethodNameTestnumber
• Все.
• Я бы сказал, да, так как интеграционные тесты не нужно запускать, если сбой модулей не выполняется.
• Простые свойства, которые просто устанавливают и получают поле, не нуждаются в проверке.

Ответ 6

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

Ответ 7

Должны ли тесты быть в одном проекте с логикой приложения?

Это зависит. Есть компромиссы в любом случае.

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

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

Насколько эти разные затраты зависят от проекта, поэтому нет универсального ответа.

Должен ли я иметь классы тестов для зеркалирования моих логических классов или у меня должно быть только столько тестовых классов, сколько мне нужно?

Нет.

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

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

Как мне назвать мои тестовые классы, методы и проекты (если они идут в разных проектах)

Вы должны называть их так, чтобы:

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

Следует ли тестировать частные, защищенные и внутренние методы или просто общедоступные?

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

Следует ли разделять тесты на единицу и интеграцию?

Это зависит от вашего выбора рамок (ов) тестирования. В зависимости от того, что лучше всего работает с вашими рамками тестирования и делает это так:

• легко найти и те единицы, и тесты интеграции, относящиеся к фрагменту кода,
• легко выполнить только модульные тесты,
• легко выполнить только тесты интеграции,
• легко выполнить все тесты.

Есть ли веская причина не иметь 100% -ный охват тестирования?

Да, есть веская причина. Строго говоря, "100% -ное охват тестирования" означает, что все возможные ситуации в вашем коде реализованы и протестированы. Это практически нецелесообразно для практически любого проекта.

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

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