Я планирую написать абстрактную классную вещь для тестирования всех моих объектов DTO и DOMAIN. Этот класс будет принимать шаблонный объект (общий тип) и использовать отражение для получения типов свойств внутри и присваивает некоторые значения по умолчанию идентифицированным типам примитивов, а позже будет утверждать эти значения типов, обратившись к ним. Таким образом, когда мои тесты DTO наследуют этот класс, большая часть кода тестируется с одной строкой кода, написанной в тесте. Это всего лишь идея и вы хотите узнать от всех вас, если я изобретаю колесо, если что-то подобное уже существует? Если есть лучший способ протестировать объект DTO и домен с меньшим и восстанавливаемым кодом.UNIT test dto и объекты домена
ответ
Я не думаю, что это хороший подход для тестирования объектов домена. По определению эти объекты инкапсулируют данные и связанные с ними поведения, они предполагают быть намного больше, чем просто немые контейнеры данных с геттерами и сеттерами. Вам придется вручную записывать единичные тесты для этих объектов так же, как вы сами написали сами объекты. Здесь вы на самом деле предполагаете проводить время в соответствии с DDD.
Что касается DTOs, вы можете посмотреть на это question.
Я согласен с тестированием объектов домена. Еще один маленький вопрос. Если некоторые из моих объектов домена просто получают/устанавливают, они также могут использоваться как DTO. могу ли я использовать объекты домена в качестве dto для разных случаев для своих веб-сервисов. – user1383012
Я бы не использовал объекты домена в качестве DTO, потому что он свяжет ваших пользователей веб-сервисов с объектами домена. Это вызовет проблемы, когда вы хотите развивать свой домен, не затрагивая клиентов веб-сервисов. – Dmitry
Мой совет:
Не модульное тестирование DTO-х. Это просто простые структуры данных с кучей геттеров и сеттеров и никакого поведения. Геттеры и сеттеры слишком тупые, чтобы их можно было протестировать (если они не инкапсулируют какую-то условную логику, которая редко бывает с DTO).
Не пытайтесь автоматизировать или обобщить тесты объектов домена. Я не вижу, как код, который проверяет их поведение, может быть повторно использован, так как все они имеют по-другому поведение по определению.
Хотя я думаю, что это своего рода негоже модульного тестирования DTOS, на основе @ ответ Дмитрия я пришел с этим классом:
[TestClass]
public class PeopleTest
{
[TestMethod]
public void OneObjectNull()
{
Person obj1 = null;
var obj2 = new Person
{
Id = "101",
Name = "George Waits",
Address = "Lake Palmer 10"
};
Assert.AreNotEqual(obj1, obj2);
Assert.AreNotEqual(obj2, obj1);
}
[TestMethod]
public void DeepEqual()
{
var obj1 = new Person
{
Id = "101",
Name = "George Waits",
Address = "Lake Palmer 10"
};
var peolpleList1 = new List<Person> { obj1 };
var peolpleList2 = new List<Person> { obj1 };
Assert.AreEqual(obj1, obj1);
CollectionAssert.AreEqual(peolpleList1, peolpleList2);
}
[TestMethod]
public void DeepNotEqual()
{
var obj1 = new Person
{
Id = "101",
Name = "George Waits",
Address = "Lake Palmer 10"
};
var obj2 = new Person
{
Id = "102",
Name = "Rachel Smith",
Address = "Lake Palmer 10"
};
var peolpleList1 = new List<Person> { obj1 };
var peolpleList2 = new List<Person> { obj2 };
Assert.AreNotEqual(peolpleList1, peolpleList2);
var group1 = new KeyValuePair<string, List<Person>>("group1", peolpleList1);
var group2 = new KeyValuePair<string, List<Person>>("group2", peolpleList2);
Assert.AreNotEqual(group1, group2);
}
[TestMethod]
public void PropertyPositive()
{
var obj1 = new Person
{
Id = "101",
Name = "George Waits",
Address = "Lake Palmer 10"
};
obj1.Address = "Parker av 101";
var obj2 = new Person
{
Id = "102",
Name = "Rachel Smith",
Address = "Lake Palmer 10"
};
obj1.Address = "Listener av 45";
Assert.AreNotEqual(obj1, obj2);
}
}
, если я правильно вас понял, вы пытаетесь проверить, если отображение до объекта domainobject и dto завершено, т.е. никакой атрибут отсутствует/потерян. если вы добавите вопрос программирования на ваш вопрос, может быть уже решение для этого. Из моего опыта в .dot его единственное достоинство efford, если у вас много dtos (> 20). ваш testapi должен учитывать свойства, которые должны быть исключены из конверсии и порядок коллекций, которые могут отличаться. – k3b
Вы должны проверять поведение, а не структуры данных ... DTO - это структура данных, вам просто нужно проверить метод агрегатов, который модифицирует их состояние с некоторым поведением (валидация, если, правила), это бесполезный тест 'set' methods ... возможно, лучше использовать некоторую библиотеку, например, проект lombok, чтобы сгенерировать их, если вы чувствуете необходимость протестировать их ... – rascio