Каковы некоторые из ограничений IdeaBlade?

Я начну проект, который нуждается в веб-интерфейсе и интерфейсе рабочего стола. Похоже, одним из решений является IdeaBlade ( http://www.ideablade.com/). Может ли кто-нибудь, кто использует его, описать его ограничения и преимущества? Это проверяемое?

Спасибо Алекс

Источник

1 ответ

Решение

Как вице-президент по технологиям в IdeaBlade, я не должен комментировать общие ограничения и преимущества DevForce в этом пространстве. Рад ответить на конкретные вопросы, хотя.

Это проверяемое? На это я могу ответить с начала ответа.

Это потенциально спорный вопрос. Люди испытывают сильные чувства по поводу того, что делает что-то проверяемым. Позвольте мне ограничиться конкретными сценариями тестирования... и затем вы оцените степень, в которой мы отвечаем вашим требованиям к тестированию.

1) DevForce поддерживает чистые объекты POCO, если вы предпочитаете это. Большинство людей предпочитают использовать сущности, которые являются производными от нашего базового класса сущностей, поэтому я ограничу свои последующие замечания полностью такими сущностями.

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

var cust = new Customer {ID=..., Name =...}; // have fun

Сборочные ссылки требуются, конечно.

3) Чтобы проверить его навигационные свойства (свойства, которые возвращают другие объекты), вы сначала создаете EntityManager (наш Unit-of-Work, контекстоподобный контейнер), добавляете или присоединяете объекты к 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). Если вы фанатик ПИ, мы для вас - неправильный выбор.

Мы стараемся оценить важные преимущества PI и делаем все возможное, чтобы реализовать их в нашем продукте. Мы делаем все возможное, чтобы скрыть основные проблемы. Тем не менее, как вы видите, наша абстракция протекает в нескольких местах. Например, мы добавляем этих членов в публичный API ваших сущностей:

  • EntityAspect (ворота к постоянному пониманию)
  • ErrorsChanged
  • PendingEntityResolved
  • PropertyChanged
  • ToQuery<>

Лично я бы сократил это до двух (EntityAspect, PropertyChanged); остальные пробрались ко мне. Для чего это стоит, наследование от объекта (как вы должны) вносит еще одну постороннюю пятерку.

Мы считаем, что мы нашли хороший компромисс между чистым PI и простотой разработки.

Мой вопрос: "Это дает вам то, что вам нужно, чтобы подтвердить ожидания без особых трений... по всему спектру от модульного до глубокого тестирования интеграции?"

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

Не стесняйтесь задавать вопросы о других сценариях тестирования, которые я мог пропустить.

Надеюсь это поможет

подопечный

Источник
Другие вопросы по тегам