Тестирование устройства - что не тестировать

Я просмотрел ряд сообщений о stackoverflow и многочисленных статьях об модульных тестах. Я просто пытаюсь понять, что я понял правильно.

Не тестируйте ничего, что не связано с логикой. Например: если на уровне службы есть метод, который просто вызывает другой метод на уровне доступа к данным, не проверяйте его.
Не тестируйте основные операции с базой данных. Если у меня есть метод в DAL, который просто вставляет объект в базу данных, скажем "public void save (Объект объекта) {...}", и на объекте, полученном с уровня сервиса, не выполняется обработка, не протестируйте его.
Мне не нужно проверять объекты на всех уровнях. Это означает, что определенное поле в объекте должно быть не нулевым, например, emailId в User Object, и это проверяется и проверяется в JSP (с использованием JS), мне не нужно проверять, как ведет себя метод DAL, если он получает emailId = NULL, потому что в идеале этого не должно быть, и это должно заботиться JS.

Что еще я не тестирую?

Ответ 1

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

Методы, не связанные с логикой

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

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

public void Save(Entity entity)
{
    this.repository.Save(entity);
}

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

Помните: простые вещи не гарантируют, что они останутся простыми.

Не тестировать операции с базой данных

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

Если вы не тестируете операции с базой данных, как вы знаете, что работает ваш компонент доступа к данным?

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

Не тестировать объект во всех слоях

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

Поэтому гораздо предпочтительнее разработать API, чтобы гарантировать, что значения не будут равны нулю.

Заключение

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

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

Test-Driven Development (TDD) - лучший способ гарантировать, что это произойдет.

Ответ 2

Не тестируйте ничего, что не может потерпеть неудачу.

Но больше к вашим точкам.

Все это зависит от того, что вы подразумеваете под логикой. Я использовал этот подход на уровне отображения. Я не тестировал весь скучный код, который скопировал значения свойств из объекта A в объект B. Плохая копия, и я дублировал копию и пропустил другую. Большая проблема. Но стоил ли он всего дополнительного тестового кода? Зависит от того, что происходит, когда приложение выходит из строя. В этом случае это стоило бы тестового кода.
Аналогично первой. Итак, Save - это хорошо и просто, но откуда вы знаете, что делали простые вещи правильно. Мессинг тех, кто работает, так же плох, как и неправильная логика бизнеса.
Вы не хотите повторно тестировать те, которые вы уже тестировали. Но вы должны выйти за рамки единичных тестов. Проводите интеграцию и регрессионное тестирование, а также модульное тестирование. Это действительно приятно, когда все части работают в вакууме, но взрываются, когда их объединяют.

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

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

Ответ 3

Простой ответ - ничего

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

В UnitTesting просто, каждый блок, в ООП, каждый класс имеет свой собственный тест. Протестируйте просто все со значениями min, max, average usecases и выполните отрицательные тесты - тесты, которые должны потерпеть неудачу, если программное обеспечение работает правильно. Также проверите обработку ошибок.

Подробнее см. ITSQB

Ответ 4

В общем, если возможно, я бы пошел на TDD-стиль. Это очень трудно достичь и требует много дисциплины, но если у вас есть это, вы никогда не захотите вернуться. Btw, TDD - это не только тестирование, но и больше о разработке программного обеспечения (также можно назвать Test-Driven-Design). Ваш дизайн развивается в соответствии с вашими испытаниями.

Марк действительно дал неплохой ответ на ваши заявления о том, что НЕ ИСПЫТАТЬ.

Мне не нужно проверять объекты на все слои. Это означает, что определенное поле в объекте должно быть не null, скажем emailId в User Object, и это проверяется и проверяется на JSP (с использованием JS), мне не нужно тестировать как ведет себя метод DAL, если он получает emailId = NULL, потому что в идеале он не должен, и это должно быть заботясь о JS.

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

Ответ 5

Не unit test среда .NET. Под этим я имею в виду, не проверяйте то, что несет ответственность Microsoft.

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

Ответ 6

Подождите, по JS вы имеете в виду JavaScript? Я предполагаю, что вы имеете в виду проверку на стороне клиента? Вы никогда не должны предполагать, что клиент проверяет что-либо при создании веб-сайта. JavaScript может быть отключен, страницы могут быть изменены или подделаны и т.д.

Ответ 7

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

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

Вот почему вы должны использовать такой инструмент, как NCover, чтобы убедиться, что 100% вашего кода выполнено в модульные тесты!

Ответ 8

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

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

Ответ 9

Я ничего не тестирую, потому что вместо этого хочу, чтобы интеграционные и/или системные тесты:

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

Подробнее см. Следует ли тестировать внутреннюю реализацию или тестировать только общественное поведение?

Обращаясь к вашему вопросу, я предлагаю, чтобы единственным кодом, который вы должны unit test, является код:

a) Что не будет протестировано вообще путем интеграции и/или тестирования системы (а если нет, то почему?)

b) Или, по какой-либо причине, должны быть протестированы перед тестированием интеграции/системы (возможно, из-за того, как параллельно разрабатывается ваша разработка проекта нескольким разработчикам)