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

Модульное тестирование - это проверка МАЛЕНЬКИХ простых битов функциональности. Обычно вы тестируете уровень данных вашего приложения, который обрабатывает все функции 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

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

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

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

Грубые приложения редко остаются бестолковыми. Со временем они разрастаются и включают уровень бизнес-объектов.

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

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

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

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

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

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

Например, модуль "Calculate some big complicated thing using 47 different variables" должен иметь кучу тестов, которые обеспечивают хорошее покрытие кода и должны охватывать все возможные пути кода, но код, который фактически сохраняет результат в базу данных, не обязательно нуждается в тесте, особенно если он выполняет простую CRUD работу.

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

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