Поблочное тестирование - Что не протестировать

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

Методы не с использованием логики

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

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

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

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

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

Отсутствие тестирования операций с базой данных.

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

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

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

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

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

Гораздо предпочтительнее разработать свой API так, чтобы гарантированно не было нулевых значений.

Заключение

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

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

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

Но больше к вашему пункту.

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

2. Аналогично пункту один. Так что "Сохранить" - это красиво и просто, но как узнать, что вы все сделали правильно. Запутать их так же плохо, как и немного ошибиться в бизнес-логике.

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

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

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

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

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

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

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

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

См. ITSQB для получения дополнительной информации по этой теме

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

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

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

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

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

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

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

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

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

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

Он основан на архитектуре тонкого сервера. Например, вместо разделения создания представлений на сервере и на клиенте используйте asp.net для создания необработанных данных JSON, а затем передайте их в JavaScript, который будет использовать свои шаблоны для генерации окончательной структуры HTML.

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

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

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