зачем мне юнит-тест бизнес-уровня в MVP - PullRequest
Новая
       21

зачем мне юнит-тест бизнес-уровня в MVP

1 голос
/ 28 марта 2012

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

public void Insert(string catName, long catParent)
{
    EntityContext con = new EntityContext();
    Category cat = new Category();
    cat.Name = catName;
    cat.Parent = catParent;
    con.Category.AddObject(cat);
    con.SaveChanges();
}

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

public void Insert(string catName, long catParent)
{
    //added to pass the test
    if(string.IsNullOrEmpty(catName)) throw new InvalidOperationException("wrong action. name is empty.");
    long parent;
    if(long.TryParse(catParent, out parent) == false) throw new InvalidOperationException("wrong action. parent didn't parsed.");
    //real bussiness logic
    EntityContext con = new EntityContext();
    Category cat = new Category();
    cat.Name = catName;
    cat.Parent = parent;
    con.Category.AddObject(cat);
    con.SaveChanges();
}

Весь мой бизнес-уровень - это простые вызовы базы данных.так что теперь я снова проверяю данные!я уже планировал сделать свою проверку в пользовательском интерфейсе и протестировать подобные вещи в тестовых единицах пользовательского интерфейса.Что я должен проверить в моем методе бизнес логики, кроме задач, связанных с проверкой?и если нет ничего для модульного тестирования, почему все говорят «модульное тестирование всех слоев» и тому подобные вещи, которые я нашел много в Интернете?

1 Ответ

2 голосов
/ 28 марта 2012

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

Предпочтительно тестировать меньшие детали, потому что:

  1. Проще писать тесты.Вам потребуется меньше данных, вы только настраиваете один объект, вам нужно вводить меньше зависимостей.

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

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

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

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

...