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

Question

В последнее время я много слышал о модульном тестировании.

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

Стоит ли модульное тестирование даже в этом сценарии или вы обычно тестируете более сложные вещи?

Спасибо

Answer 1

Модульное тестирование - это тестирование отдельных блоков кода - один метод, не более.

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

Есть место для обоих типов тестирования (и других типов - регрессия, производительность и т. Д ...) в любом программном проекте, приложении CRUD или нет.

Answer 2

Если все ваше приложение - CRUD, тогда нет смысла его модульное тестирование. Теперь, если есть какая-либо бизнес-логика, манипулирующая значениями, когда они выходят из БД, или проверяющая их перед входом, да, это хорошая идея для создания модульных тестов. Тестирование части CRUD не относится к модульному тестированию IMO.

Answer 3

Cruddy приложения редко остаются грубыми.В конечном итоге они включают слой бизнес-объектов.

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

Answer 4

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

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

Например, модуль «Вычислить некоторые большие сложные вещи, используя 47 различных переменных» должен иметькуча тестов, которые обеспечивают хорошее покрытие кода и должны охватывать все возможные пути кода, но код, который фактически сохраняет результаты в базу данных, не обязательно нуждается в тесте, особенно если он выполняет простую работу CRUD.

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

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

Answer 5

Проверьте все, что может сломаться .

Конечно, вам нужно проверить свои операции CRUD, особенно если у вас есть приложение, ориентированное на данные.И по моему опыту такие тесты очень полезны, потому что они могут обнаружить множество ошибок в отображениях, логике хранимых процедур, ошибках в модели данных, неправильных данных и т. Д.

Answer 6

Модульное тестирование - это тестирование МАЛЕНЬКИХ простых битов функциональности.Обычно вы тестируете уровень данных вашего приложения, который обрабатывает все функции CRUD.Тест для создания и извлечения может выглядеть следующим образом:

    PrimaryKey = InsertObject(TestObject)

    if PrimaryKey = 0 then

     AssertTestFailed("Primary Key Not Returned.")

    end if


    NewInstanceOfObject = GetObject(PrimaryKey)

    If NewInstanceOfObject <> TestObject then
      AssertTestFailed("Record not located.")
else
      AssertTestPassed("This Code is awesome UnitTest Passed.")
    end if