IdeaBlade의 한계점은 무엇입니까?

Question

웹 및 데스크톱 인터페이스가 필요한 프로젝트를 시작하겠습니다. 한 가지 해결책은 IdeaBlade (http://www.ideablade.com) 인 것 같습니다. 사용하는 사람은 제한 사항과 장점을 설명 할 수 있습니까? 테스트할만한가요? 내가이 공간에서 DevForce 제한 및 장점에 일반적으로 언급하는

감사합니다, IdeaBlade에서 기술 담당 부사장으로 알렉스

Answer 1

은 아니다. 그래도 특정 질문에 답변 해 주셔서 감사합니다.

테스트 할 수 있습니까? 이것에 응답의 처음에 응답해서 좋다.

잠재적으로 논쟁의 여지가있는 질문입니다. 사람들은 무엇이 시험 가능한지에 대해 강한 감정을 가지고 있습니다. 특정 테스트 시나리오에 자신을 국한시키고 테스트 요구 사항을 충족시키는 정도를 판단합니다.

1) DevForce는 사용자가 선호하는 경우 순수 POCO 항목을 지원합니다. 대부분의 사람들은 기본 엔티티 클래스에서 파생 된 엔티티를 사용하기를 원하므로 필자는 후속 발언을 전적으로 해당 엔티티에 한정합니다.

2) 원하는 엔트리를 사용하여 이러한 엔티티를 새로 만들 수 있으며 다른 설정없이 (비 네비게이션) 속성을 가져오고 설정할 수 있습니다.

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

조립 참조 자료는 물론 필요합니다.

3) 네비게이션 속성 (다른 엔티티를 반환하는 속성)을 테스트하려면 먼저 엔티티 관리자 (EntityManager) (컨셉과 같은 컨테이너)를 추가하거나 엔티티를 EM에 추가 또는 첨부하고 가기. 기본 클래스에서 상속 한 Entities의 탐색 속성은 해당 컨테이너를 통해 관련 엔터티를 찾을 것으로 기대합니다.

4) 대부분의 자동화 된 테스트에서 EntityManager는 연결이 끊긴 상태로 만들어져 서버 나 데이터베이스에 도달하지 못하도록합니다.

주문, 고객, 일부 OrderDetails를 추가 할 수 있습니다. 그들 모두는 당신의 테스트의 컨텍스트 내에서 구성됩니다 ... 어디서나 검색되지 않습니다.

이제 order.Customer는 고객 테스트를 반환합니다. order.OrderDetails는 테스트 세부 정보를 반환합니다. 준비 작업은 EM, 테스트 엔티티를 작성하여 이러한 엔티티에 고유 ID가 있고 연관되어 있는지 확인하는 것입니다.

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 

전각은 메모리 데이터베이스 역할 :

여기 예시적인 서열이다. 각 테스트가 교차 시험 오염을 제거하기 전에

5) 이제

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를 만들 LINQ를 사용할 수 있습니다.

7) 나는 일탈 (deviant) 사례를 포함한 표준 테스트 데이터 수집으로 EM을 채우기 위해 소위 "데이터 마더"테스트 도우미 클래스를 작성합니다.

8) EntityManager의 테스트 엔터티 캐시를 파일 또는 테스트 프로젝트 리소스로 내보낼 수 있습니다.테스트가 실행되면 DataMother는 이러한 테스트 엔티티를 검색하고 복원 할 수 있습니다.

단위 테스트에서 통합 테스트로 점차적으로 옮겨 가고 있음을 관찰하십시오. 그러나 (지금까지) 내 테스트에는 서버 나 Entity Framework 또는 데이터베이스에 대한 액세스가 필요하지 않습니다. 실행 속도가 빠르고 설치 장애를 분산시키는 데 덜 취약합니다.

물론 통합 테스트를 통해 서버를 사용할 수 있으며 로컬, LAN 및 웹 시나리오에 대해 서버와 데이터베이스를 쉽게 전환 할 수 있습니다.

9) 상호 작용 테스트를 위해 쿼리 저장, 변경, 추가, 제거 및 기타 이벤트를 차단할 수 있습니다.

10) 설명한 모든 내용은 일반 .NET과 Silverlight 및 내가 만난 모든 테스트 프레임 워크에서 작동합니다.

단점이라면, 우리 제품을 모의 친화적이라고 설명하지는 않습니다.

나는 우리가 Persistence Ignorant (PI)가 아니라는 것을 쉽게 인정합니다. 당신이 PI 광신자라면, 우리는 당신을위한 잘못된 선택입니다.

우리는 PI의 중요한 이점을 이해하고 제품에서 실현하기 위해 최선을 다하고 있습니다. 우리는 프레임 워크의 우려를 시야에서 깨뜨릴 수있는 일을합니다. 그래도 알다시피, 우리의 추상화는 몇 군데에서 유출됩니다.

는

는

는

ToQuery <>

을하여 PropertyChanged PendingEntityResolved ErrorsChanged (의식을 지속성 게이트웨이)

• EntityAspect 예를 들어, 우리는 당신의 엔티티의 공개 API에이 멤버를 추가

  개인적으로 저는 이것을 두 개로 자릅니다 (EntityAspect, PropertyChanged). 다른 사람들은 나 한테 엿 먹어. 가치가있는 것을 위해, 당신이해야만하는 것처럼 Object로부터 상속받는 것은 다른 5 개의 공헌에 기여합니다.

  우리는 순수한 P.I. 및 개발 용이성.

  제 질문은 "단위 테스트에서부터 통합 테스트까지 전체 스펙트럼에서 마찰이없는 기대치를 검증하는 데 필요한 것을 제공합니까?"

  나는 유사 제품과의 마찰이 적은 비슷한 시설을 얻는 방법을 확실히 알고 싶어합니다. 또한 응용 프로그램 테스트에 대한 지원을 향상시킬 수있는 방법에 대한 제안을 받기 위해 열심히 노력합니다.

  간과 할 수있는 다른 테스트 시나리오에 대한 질문이 있으면 언제든지 후속 조치를 취하십시오.

  희망이 아주 좋은, 당신의 대답을

  워드에게