Как вице-президент по технологиям в IdeaBlade, я не должен комментировать общие ограничения и преимущества DevForce в этом пространстве. Рад ответить на конкретные вопросы, хотя.
Это проверяемое? На это я могу ответить началом ответа.
Это потенциально спорный вопрос. Люди испытывают сильные чувства по поводу того, что делает что-то проверяемым. Позвольте мне ограничиться конкретными сценариями тестирования ... и затем вы оцените степень, в которой мы отвечаем вашим требованиям тестирования.
1) DevForce поддерживает чистые объекты POCO, если вы предпочитаете это. Большинство людей предпочитают использовать сущности, которые являются производными от нашего базового класса сущностей, поэтому я ограничу свои последующие замечания исключительно такими сущностями.
2) Вы можете обновить такую сущность, используя любой понравившийся вам ctor, и получить и установить его (не навигационные) свойства без других настроек.
var cust = new Customer {ID=..., Name =...}; // have fun
Ссылка на сборку требуется, конечно.
3) Чтобы проверить его навигационные свойства (свойства, которые возвращают другие сущности), вы сначала создаете EntityManager (наш блок работы, контекстоподобный контейнер), добавляете или присоединяете сущности к EM, и готово. , Навигационные свойства сущностей, унаследованных от нашего базового класса, предполагают поиск связанных сущностей через этот контейнер.
4) В большинстве автоматических тестов EntityManager создается в отключенном состоянии, чтобы он никогда не пытался связаться с сервером или базой данных.
Вы можете добавить к нему Заказ, Клиент, некоторые детали Заказа; обратите внимание, что все они созданы в контексте ваших тестов ... нигде не получены.
Теперь заказ. Клиент возвращает тестируемого Клиента; order.OrderDetails возвращает ваши тестовые данные. Ваша подготовка состоит из создания EM, тестовых объектов, обеспечения того, чтобы эти объекты имели уникальные идентификаторы и были связаны.
Вот пример последовательности:
var mgr = new EntityManager(false); // create disconnected
var order = new Order {ID = ..., Quantity = 1, ...};
var customer = new Customer {ID = 42, Name = "ABC", };
mgr.AttachEntity(order);
mgr.AttachEntity(customer);
order.Customer = customer; // associate them
EM действует как база данных в памяти.
5) Вы можете использовать LINQ сейчас
var custs = mgr.Customers.Where(c => c.Name.StartsWith("A").ToList();
var orders = mgr.Orders.Where(o => o.Customer.Name.StartsWith("A")).ToList();
6) Конечно, я всегда создаю новый EntityManager перед каждым тестом, чтобы исключить загрязнение между тестами.
7) Я часто пишу так называемый класс помощника по тестированию «Data Mother», чтобы заполнить EM стандартным набором тестовых данных, включая отклоняющиеся случаи.
8) Я могу экспортировать кэш тестовых сущностей EntityManager в файл или ресурс тестового проекта. При выполнении тестов DataMother может извлекать и восстанавливать эти тестовые объекты.
Заметьте, что я постепенно ухожу от модульного тестирования к интеграционному тестированию. Но (пока) мои тесты не требуют доступа к серверу, Entity Framework или базе данных. Они работают быстро и менее подвержены отвлекающим сбоям установки.
Конечно, вы можете попасть на сервер в тестах глубокой интеграции, и вы можете легко динамически переключать серверы и базы данных для локальных, локальных и веб-сценариев.
9) Вы можете перехватывать запросы, сохранять, изменять, добавлять, удалять и другие события для тестирования взаимодействия.
10) Все, что я описал, работает как в обычном .NET, так и в Silverlight, а также в каждой тестовой среде, с которой я столкнулся.
С другой стороны, я бы не охарактеризовал наш продукт как дружественный.
Я с готовностью признаю, что мы не невежественны (ПИ). Если вы фанатик ПИ, мы для вас - неправильный выбор.
Мы стараемся оценить важные преимущества PI и делаем все возможное, чтобы реализовать их в нашем продукте. Мы делаем все возможное, чтобы скрыть основные проблемы. Тем не менее, как вы видите, наша абстракция протекает в нескольких местах. Например, мы добавляем этих участников в общедоступный API ваших объектов:
- EntityAspect (ворота к постоянному осознанию)
- ErrorsChanged
- PendingEntityResolved
- PropertyChanged
- ToQuery <>
Лично я бы сократил это до двух (EntityAspect, PropertyChanged); остальные пробрались ко мне. Для чего бы это ни стоило, наследование от Object (как вы должны) дает еще одну постороннюю пятерку.
Мы чувствуем, что добились хорошего компромисса между чистым P.I. и простота разработки.
Мой вопрос: «дает ли это вам то, что вам нужно, чтобы подтвердить ожидания без особых трений ... по всему спектру от единичного до глубокого интеграционного тестирования?»
Мне, конечно, любопытно узнать, как вы получаете аналогичное оборудование с меньшим трением с аналогичными продуктами. И готовы принять предложения о том, как мы можем улучшить нашу поддержку тестирования приложений.
Не стесняйтесь задавать вопросы о других сценариях тестирования, которые я мог пропустить.
Надеюсь, это поможет
Ward