2010-06-21 35 views
7

Trong dự án của tôi, tôi viết kiểm tra bằng cách sử dụng khung kiểm thử đơn vị của Microsoft. Tất cả các bài kiểm tra của tôi vượt qua khi tôi chạy chúng từ Visual Studio nhưng khi tôi chạy thử nghiệm từ MSBuild tất cả các bài kiểm tra thất bại với thông điệp erorr sau:Ngoại lệ MSTest: Unit Test Adapter đã loại trừ ngoại lệ: Loại không được giải quyết cho thành viên

Unit Test Adapter threw exception: Type is not resolved for member SomeType,SomeAssembly Version=assemblyVersion, Culture=neutral, PublicKeyToken=..

Việc lắp ráp không tìm thấy là một hội đồng bên thứ 3 tham chiếu bởi tất cả của các dự án.

Các xây dựng kịch bản được sử dụng bởi TFS vì vậy tôi đã aded những dòng sau:

<RunTest>true</RunTest> 

<ItemGroup> 
    <MetaDataFile Include="$(BuildProjectFolderPath)myproject.vsmdi"> 
     <TestList>CI_Tests</TestList> 
    </MetaDataFile> 
</ItemGroup> 

Tôi đã tìm thấy this post cho thấy một giải pháp cho vấn đề này nhưng tiếc là tôi không thể chnage các tập tin trên TFS máy chủ.

Trợ giúp!

+0

là lắp ráp này được cài đặt trong GAC? –

+0

không, đó là một phiên bản .NET đơn giản gọi là Common.Logging –

Trả lời

3

Điều đầu tiên cần kiểm tra là nếu hội đồng này được sao chép vào thư mục mà từ đó msbuild chạy thử nghiệm. Nó có thể là trường hợp bạn có một bản sao trong thư mục bin/Debug của bạn vì một số lý do lịch sử, nhưng sự phụ thuộc không được thiết lập đúng trong dự án.

+0

nope, dll được sao chép ... –

+0

là phiên bản đúng? và phụ thuộc của dll này? – Grzenio

+0

Tôi nghĩ rằng phiên bản này là chính xác và phụ thuộc duy nhất dll này có. NET BCL –

9

Tôi gặp phải sự cố tương tự trong các bài kiểm tra đơn vị của mình. Bài báo liên kết ở trên chỉ ra rằng vấn đề là VSTS gây ra việc sao chép một số đối tượng trong CallContext của luồng.

Đối với những gì nó có giá trị, trong trường hợp của tôi vấn đề là tôi đã đặt thủ công một đối tượng trong CallContext của chủ đề, điều này gây ra ngoại lệ này. Tôi đã có thể giải quyết điều này bằng cách xóa CallContext trong thói quen TestCleanup của tôi. Tôi không phải thay đổi bất kỳ tệp nào ở bất kỳ đâu.

+1

[TestCleanup] public void Cleanup() {CallContext.FreeNamedDataSlot ("__ Key"); } - Có, nó đã làm việc cho tôi quá, cảm ơn! – Fabio

+0

Nhóm của tôi có vấn đề tương tự với các bài kiểm tra đơn vị của chúng tôi. Chúng tôi đã có thể làm cho họ làm việc bằng cách sử dụng GetContext() và SetContext() thay vì LogicalGetContext() và LogicalSetContext(). Lợi ích của phương pháp này là chúng ta không phải nhớ "tự do" các mục mà chúng ta đặt trong ngữ cảnh. Chúng tôi nghĩ rằng nhược điểm của điều này là nó có thể không hoạt động trong các kịch bản AppDomain chéo. – Paul

+0

Cảm ơn, @Telewin và @Fabio !!! Trợ giúp lớn !!! :) –

4

Tôi cũng đã chạy vào cùng một vấn đề nhưng nơi tôi đã có InitialMapation StructureMap được thực hiện trong constructor cho một lớp thử nghiệm cơ bản.

Tôi đã có thể khắc phục sự cố bằng cách di chuyển cuộc gọi từ hàm tạo sang phương thức [TestInitialize]. Tôi cũng đảm bảo rằng phương thức [TestCleanUp] được xử lý trong thùng chứa StructureMap đã tạo. Sau này MSBuild (2010) sẽ chạy qua các bài kiểm tra mà không nâng cao lỗi này.

1

Đã lỗi này

Unit Test Adapter threw exception: 
Type is not resolved for member 'NHibernate.HibernateException,NHibernate 

Khi nó bật ra vấn đề là trong ngoại lệ ném vào constructor tĩnh cho kỳ thi này. Nó hoàn toàn không liên quan đến vẻ ngoài của thông điệp và đã xảy ra trong quá trình tạo DB bằng BuildSchema.

Thông báo lỗi rất không rõ ràng bởi MSTest khiến tôi mất nhiều thời gian và căng thẳng. đưa di cư đến một cái gì đó tốt hơn như NUnit trong danh sách TODO của chúng tôi.

0

This article giải quyết vấn đề của tôi với lỗi này:

To recap, MyCustomException was thrown at very early stage of test execution. The dll that contained it was not loaded yet so Unit Test Adapter indeed could not reach it.

Các vấn đề liên quan