Tại sao visual studio 2012 không tìm thấy bài kiểm tra của tôi?


221

Tôi có một số thử nghiệm sử dụng tích hợp Microsoft.VisualStudio.TestTools.UnitTesting, nhưng không thể chạy chúng.

Tôi đang sử dụng visual studio 2012 cuối cùng.

Tôi có một giải pháp của hai dự án; Người ta kiểm tra, using Microsoft.VisualStudio.TestTools.UnitTesting, [TestClass]trước lớp, [TestMethod]trước khi phương pháp thử nghiệm và tài liệu tham khảo Microsoft.VisualStudio.QualityTools.UnitTestFramework(phiên bản 10.0.0.0, phiên bản runtime v2.0.50727). Tôi đã thử khung dot-net 3.5, 4 và 4.5 khác đưa ra lỗi nhắm mục tiêu lại.

Tôi đã cố gắng xây dựng giải pháp và dự án. Trình thám hiểm thử nghiệm có thông báo `Xây dựng giải pháp của bạn để khám phá tất cả các bài kiểm tra có sẵn. Nhấp vào "chạy tất cả" để xây dựng, khám phá và chạy tất cả các thử nghiệm trong giải pháp của bạn.

Vì vậy, câu hỏi là: Làm thế nào để tôi có được phòng thu trực quan để tìm các bài kiểm tra?


Cũng đã cố gắng làm theo điều này: http://msdn.microsoft.com/en-US/l Library / ms379625% 28v = VS.80% 29.aspx nhưng không thành công: Tôi bị kẹt trong phần bắt đầu, khi được yêu cầu nhấp chuột phải và chọn create tests. Không có create tests.


Tôi có bài kiểm tra này (nó biên dịch, nhưng không hiển thị trong trình khám phá thử nghiệm):

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace tests {
    [TestClass]
    public class SimpleTest {
        [TestMethod]
        public void Test() {
            Assert.AreEqual("a","a", "same");
        }
    }
}

Bây giờ tôi đã phát hiện ra (xem câu trả lời đã bị xóa bên dưới) rằng đó là vì nó nằm trên một ổ đĩa chung, nhưng tôi chưa biết cách khắc phục nó. (một cái gì đó về cài đặt bảo mật có thể).


Phiên bản VS 2012 nào? Bạn có thể tải xuống một người chạy thử nghiệm như TestDriven.Net hoặc có một người trong Resharper.
Brett Allred

Tôi đang sử dụng visual studio 2012 cuối cùng.
ctrl-alt-delor

Vui lòng chia sẻ phiên bản khung và phiên bản thư viện UnitTesting mà bạn đã thêm làm tài liệu tham khảo
Adil

5
Trong trường hợp của tôi, việc xóa tệp app.config đã sửa lỗi trình khám phá đơn vị
Chris Richner

4
Hãy thử tìm kiếm các lỗi trong danh mục 'Kiểm tra' trong cửa sổ đầu ra. Tôi tạo các kiểm tra chức năng từ bản dựng phát hành và khi tôi cố gắng gỡ lỗi bằng cách sử dụng bản dựng gỡ lỗi (có các dll nằm trong một cấu trúc thư mục khác), tôi không gặp bất kỳ lỗi xây dựng nào mà phải xem xét nghiệm từ menu kéo xuống. Khi tôi giải quyết những vấn đề đó, các bài kiểm tra bắt đầu xuất hiện trong Test Explorer
gDexter42

Câu trả lời:


227

Tôi đã có cùng một triệu chứng, nhưng trong những trường hợp khác nhau.

Tôi đã phải thêm một bước nữa vào giải pháp của Peter Lamberg - Làm sạch giải pháp / dự án của bạn.

Dự án không mong muốn nhất của tôi x64. Khi tôi tạo dự án, nó ban đầu nhắm mục tiêu x86.

Sau khi chuyển sang x64, tất cả các bài kiểm tra đơn vị của tôi biến mất.

Tôi đã phải vào Menu Kiểm tra -> Cài đặt thử nghiệm - Kiến trúc bộ xử lý lỗi -> x64.

Họ vẫn không xuất hiện.

Đã xây dựng.

Vẫn không xuất hiện.

Cuối cùng đã làm sạch

Sau đó, họ xuất hiện.

Tôi thấy Clean Solution và Clean khá hữu ích trong việc lấy các giải pháp để chơi bóng khi cài đặt đã thay đổi. Đôi khi tôi phải đi đến cùng cực và xóa objbin danh bạ và thực hiện xây dựng lại.


Trong khi làm sạch đôi khi không có ích, nó không phải là vấn đề. Tôi có một vấn đề với các dự án trên các ổ đĩa mạng. Và thực tế là bản dựng giúp bao giờ chỉ là một triệu chứng của công cụ xây dựng lỗi.
ctrl-alt-delor

7
Ồ "Giải pháp sạch" thực sự có hiệu quả (trái ngược với việc chỉ xây dựng lại tất cả). Tôi nghĩ rằng điều này đã dừng lại là một hack hữu ích trong Visual Studio 6.0!
Dave

"Sạch" không làm việc cho đồng nghiệp của tôi, người có vấn đề này. Nó hoạt động với cô ấy sau khi xóa tất cả mã nguồn khỏi không gian làm việc TFS của cô ấy và nhận được bản mới nhất (w / ghi đè). Sau đó, nó làm việc tuyệt vời!
Michael R

2
Đây là nó cho tôi. Trong một giải pháp với sự pha trộn của x86, Bất kỳ CPU, x64, một thử nghiệm cụ thể của dự án không được tìm thấy. Tôi đã làm sạch giải pháp, thay đổi kiến ​​trúc mặc định của cài đặt thử nghiệm và xây dựng lại và sau đó mọi thứ có thể được nhìn thấy. Nó thực sự vô nghĩa, vì thay đổi kiến ​​trúc đã phát hiện ra các thử nghiệm được biên dịch theo kiến ​​trúc CPU khác.
Ben H

2
Ngay khi tôi thay đổi bộ xử lý mặc định - tất cả các thử nghiệm của tôi đã hiển thị. Cảm ơn rất nhiều cho việc này!
Dan Nhưng

160

Vui lòng thêm từ khóa công khai vào định nghĩa lớp học của bạn. Lớp kiểm tra của bạn hiện không thể nhìn thấy bên ngoài lắp ráp riêng của nó.

namespace tests {
    [TestClass]
    public class SimpleTest {
        [TestMethod]
        public void Test() {
            Assert.AreEqual("a","a", "same");
        }
    }
}

24
Đã làm điều đó cho tôi, gần như xấu hổ tôi đã không tự mình tìm ra :)
Landi

5
Tôi cũng gặp vấn đề này, tôi đã bị gây ra bởi sự [TestMethod]tĩnh do bản sao của mã khác.
Seph

2
@Seph: Tôi [TestMethod]ở đâu tĩnh vì đó là những gì UserTest1.cstrong dự án thử nghiệm mới đã có! Cũng giải quyết vấn đề của tôi.
Andre Luus

4
Cũng đừng đặt statictrước phương pháp của bạn. Tôi không biết tại sao tôi lại làm điều đó theo thói quen thường xuyên như vậy.
levininja

1
Điều này đã làm điều đó cho tôi, thật thú vị khi bạn có thể mất quá nhiều thời gian cho một thứ đáng lẽ phải quá rõ ràng. Cảm ơn câu trả lời Joe King
Thulani Chivandikwa 9/2/2016

58

Điều này đôi khi hoạt động.

Kiểm tra xem kiến ​​trúc bộ xử lý trong menu Kiểm tra có khớp với cấu trúc bạn sử dụng để xây dựng giải pháp không.

Kiểm tra -> Cài đặt kiểm tra -> Kiến trúc bộ xử lý mặc định -> x86 / x64

Như đã đề cập trong các bài đăng khác, hãy đảm bảo bạn mở cửa sổ Test Explorer. Kiểm tra -> Windows -> Kiểm tra Explorer

Sau đó, xây dựng lại dự án với các thử nghiệm sẽ làm cho các thử nghiệm xuất hiện trong Test Explorer.

Chỉnh sửa: Như Ourjamie đã chỉ ra dưới đây, thực hiện một bản dựng sạch cũng có thể giúp ích. Thêm vào đó, đây là một điều nữa tôi gặp phải:

Hộp kiểm "Xây dựng" chưa được sử dụng trong Trình quản lý cấu hình cho dự án thử nghiệm mới mà tôi đã tạo theo giải pháp.

Chuyển đến Build -> Trình quản lý cấu hình. Hãy chắc chắn rằng dự án thử nghiệm của bạn đã kiểm tra hộp kiểm xây dựng cho tất cả các cấu hình giải pháp và nền tảng giải pháp.


Vâng, đây có thể là những lý do khác khiến nó không hoạt động, nhưng hãy xem câu trả lời được đánh dấu bên dưới để biết lý do tại sao nó không hoạt động với tôi. (thư mục dùng chung bị tắt theo mặc định), nếu bạn có thể cho chúng tôi biết cách thay đổi điều này tôi sẽ cung cấp cho bạn một số điểm.
ctrl-alt-delor

Không có bộ xử lý như x64, nhưng tôi nghĩ microsoft sử dụng thuật ngữ này cho x86-64 / amd64 / x86e. Cũng không có x86, chỉ là gia đình x86. X là viết tắt của ẩn số, vì vậy các thành viên của gia đình x64 sẽ là 164, 264, 364 CƠ OR là x86 một bộ xử lý 86 bit.
ctrl-alt-delor

cảm ơn câu trả lời của bạn, nó giúp tôi (tôi đã chuyển từ bản dựng x86 sang bản dựng x64)
enguerran

Ngay cả trong VS 2015 có cửa sổ Test Explorer mở cũng hoạt động. Vui mừng vì tôi cũng có thể chạy thử nghiệm từ dòng lệnh.
Bryan

32

Tôi có Visual Studio 2012 và tôi không thể xem các Thử nghiệm trong Test Explorer,

Vì vậy, tôi đã cài đặt như sau: NUnit Test Adapter

Điều đó đã khắc phục vấn đề cho tôi!


1
Cũng có sẵn qua NuGetInstall-Package NUnitTestAdapter
Darren Hale

Cảm ơn @DarrenHale. Trong khi tìm kiếm gói này trong NuGet, tôi cũng tìm thấy một gói có tên NUnit TestAd CHƯƠNG bao gồm NUnit 2.6.4 Framework .
ray

18

Theo kinh nghiệm gần đây của tôi, tất cả những điều trên không hoạt động. Phương pháp kiểm tra của tôi

public async void ListCaseReplace() { ... }

đã không hiển thị nhưng biên dịch tốt. Khi tôi xóa asynctừ khóa, bài kiểm tra đã xuất hiện trong Test Explorer. Đây là async voidmột phần của phương pháp 'lửa và quên'. Làm phương phápasync Task và bạn sẽ nhận được bài kiểm tra của bạn trở lại!

Ngoài ra, việc không đặt cấu hình của dự án Kiểm tra thành "Xây dựng" cũng sẽ ngăn các kiểm tra hiển thị. Trình quản lý cấu hình> Kiểm tra kiểm tra của bạn để xây dựng.


2
Tôi đã mất một thời gian để tìm ra điều này. Tôi đã cấu trúc lại một vài phương thức để không đồng bộ và chỉ cần thêm từ khóa vào các bài kiểm tra. Chỉ đến khi tôi mã hóa một bài kiểm tra đơn vị mới với điều này thì tôi mới nhận thấy các bài kiểm tra khác cũng bị thiếu. Tôi tìm thấy câu trả lời này giải thích tại sao điều này xảy ra.
julealgon

12

Vì dự án nằm trên một ổ đĩa chung như poster ban đầu đã chỉ ra. VS.NET cần tin tưởng vị trí mạng trước khi nó tải và chạy các bản thử nghiệm của bạn. Có một bài đọc của bài blog này .

Để cho phép VS.NET tải những thứ của mạng chia sẻ, người ta cần thêm chúng (chia sẻ) vào các vị trí đáng tin cậy. Để thêm một vị trí vào danh sách tin cậy đầy đủ chạy (rõ ràng sửa đổi theo yêu cầu cho môi trường của bạn):

 caspol -m -ag 1.2 -url file:///H:/* FullTrust

Để xác minh hoặc liệt kê các vị trí đáng tin cậy hiện có chạy:

 caspol -lg

Câu trả lời này không được xác minh bởi người hỏi, vì tôi không còn quan tâm đến câu trả lời. Nếu nó hoạt động cho bạn (hoặc không), sau đó thêm một bình luận bên dưới.
ctrl-alt-delor

6
@richard Vì vậy, bạn chấp nhận một câu trả lời mà bạn đã không xác minh và đánh giá thấp các câu trả lời khác mô tả các giải pháp cho các nguyên nhân khác nhau của vấn đề của bạn? ....Lạ nhỉ!
Stephan Bauer

1
Điều này hóa ra là vấn đề đối với tôi, nhưng không phải là giải pháp. Tôi đã di chuyển mọi thứ địa phương và tất cả các bài kiểm tra đã được tìm thấy! Cảm ơn!
Travis Swientek

1
CasPol.execó thể được tìm thấy dưới %windir%\Microsoft.NET\Framework[64]\[version]. Xác minh rằng bạn đang thiết lập chính sách cho kiến ​​trúc phù hợp. Nguồn: msdn.microsoft.com/en-us/l
Library / cb6t8dtz% 28v = vs.100% 29.aspx

Đây cũng là vấn đề đối với tôi. Thật khó chịu khi VS không nhận chúng nhưng không đưa ra dấu hiệu nào về nguyên nhân!
kaybee99

10

Một vấn đề tôi đã tìm thấy là các bài kiểm tra không được tìm thấy trong Test Explorer (không có gì hiển thị) nếu giải pháp đang chạy khỏi ổ đĩa mạng / vị trí mạng / ổ đĩa chung

Bạn có thể khắc phục điều này bằng cách thêm một biến môi trường.

COMPLUS_LoadFromRemoteSource và đặt giá trị của nó thành 1


6

Tôi đã có cùng một vấn đề .. Trong trường hợp của tôi, đó là do một tài sản tư nhân gây ra TestContext .

Thay đổi nó thành các trợ giúp sau:

public TestContext TestContext
{
    get;
    set;
}

Sau khi làm sạch và xây dựng giải pháp (như được mô tả trong câu trả lời của @Ourjamie), các phương pháp thử nghiệm trong lớp thử nghiệm bị ảnh hưởng đã có sẵn trong Test Explorer.


OK các triệu chứng tương tự, vì vậy sẽ loại bỏ bỏ phiếu, nếu bạn làm rõ những gì bạn đã thay đổi (từ những gì).
ctrl-alt-delor

1
Tôi đã hoàn toàn giống nhau, tôi đã theo dõi chủ đề hoàn chỉnh, sau đó đến cái này và đưa tôi đến ý tưởng để đặt nó ở chế độ công khai, bingo: các thử nghiệm mới của tôi xuất hiện. Tôi hiểu các nhận xét trước đây nhưng ... vì bài viết này mang lại cho chúng tôi từ Google ... đây là chủ đề để đọc khi các bài kiểm tra không hiển thị.
edelwater

1
Đây là nguyên nhân của vấn đề của tôi. Tôi đã có một trường cho giao diện phụ thuộc như một trường riêng. Bạn là một người cứu rỗi cuộc sống!
Alex

6

Tôi gặp vấn đề tương tự trong khi cố gắng mở giải pháp trên mạng chia sẻ. Test Explorer sẽ không phát hiện đơn vị nào trong trường hợp này. Giải pháp hóa ra là:

Bảng điều khiển -> Tùy chọn Internet -> Tab "Bảo mật" -> Nhấp vào "Mạng nội bộ" và thêm địa chỉ IP của máy chủ hoặc tên máy chủ giữ chia sẻ mạng vào danh sách "Trang web".

Sau khi làm điều này, tôi biên dịch lại giải pháp và bây giờ các bài kiểm tra đã xuất hiện. Điều này khá giống với câu trả lời của @BigT.


6

Danh sách kiểm tra nhanh để giải quyết một số vấn đề kiểm tra phổ biến. Đảm bảo rằng:

  1. Lớp kiểm tra và phương pháp kiểm tra là public
  2. Lớp kiểm tra có [TestClass] thuộc tính
  3. Phương pháp kiểm tra có [TestMethod]thuộc tính

Nếu điều này không có ích, hãy thử làm sạch, xây dựng lại giải pháp và khởi động lại Visual Studio.


Điều này sẽ khắc phục vấn đề của hầu hết khách truy cập cho câu hỏi này và tóm tắt hầu hết các câu trả lời, tuy nhiên nó không bao gồm vấn đề trong câu hỏi.
ctrl-alt-delor 18/03/2016

1
Cảm ơn bạn. UTA001: TestClass attribute defined on non-public class
Jarek Przygódzki

6

Tôi đã nhận được lỗi: "Failed to initialize client proxy: could not connect to vstest.discoveryengine.exe."

Hãy thử chạy Visual Studio với tư cách Quản trị viên. Điều đó làm việc cho tôi.

Có một bài viết khác về Stack Overflow thảo luận về lỗi này và cùng một giải pháp hoạt động cho chúng. Câu hỏi vẫn còn tại sao điều này hoạt động.


3
Làm việc cho tôi quá! Tôi nghĩ rằng đây là một vấn đề riêng biệt.
Justin Morgan

2
Này người đàn ông làm việc này. Cảm ơn bạn rất nhiều .. Bất kỳ cách giải quyết nào để làm cho nó hoạt động mà không chạy như quản trị viên?
Sriram Sakth Xoay

2
Xin lỗi tôi không nghĩ rằng chạy như một quản trị viên là một giải pháp tốt. Trừ khi bằng chứng rằng đây là cách duy nhất.
ctrl-alt-delor

Chạy như quản trị viên thường không phải là một vấn đề lớn. Nhưng một trong những vấn đề là bạn không thể gửi Workitem đến triển vọng.
Edward Olamisan

Đã chỉnh sửa câu trả lời của bạn để liên kết đến bài đăng SO có liên quan, hy vọng bạn không phiền. Tôi đồng ý với Sriram và richard. Mặc dù điều này hoạt động, nó là một cách giải quyết, không phải là một giải pháp. Tại sao nó thậm chí hoạt động ở tất cả dường như không rõ ràng.
Steven Jeuris

4

Đôi khi tôi nhận được các triệu chứng tương tự.

Những gì tôi đã làm là:
1. Đóng cửa sổ Test Explorer
2. Làm sạch giải pháp
3. Xây dựng lại giải pháp
4. Khởi chạy lại cửa sổ Test Explorer từ Test -> Windows -> Test Explorer.

Và tôi đã kiểm tra trong cửa sổ Test Explorer.


Tôi không nghĩ đây là vấn đề tương tự.
ctrl-alt-delor

3
Tôi nghĩ đó cùng một vấn đề, nó chỉ gây ra bởi một thứ khác.
Stephan Bauer

2

Từ thanh menu trên đầu ...

Kiểm tra -> Chạy -> Tất cả các Kiểm tra

Bạn cũng có thể xem tất cả các thử nghiệm từ Test Explorer (Test -> Windows -> Test Explorer)

Hơn nữa với VS 2012, nếu bạn bỏ lỡ bất cứ điều gì, hãy thử tìm kiếm bằng thanh Khởi động nhanh ở trên cùng bên phải (Ctrl + Q) "Kiểm tra"

Hi vọng điêu nay co ich.


Tôi đã thử điều đó, cả hai đều làm việc với nunit. Nhưng lần này tôi đang cố gắng chạy các bài kiểm tra của người khác bằng văn bản Microsoft.VisualStudio.TestTools.UnitTesting, có ai biết tôi đang làm gì sai không?
ctrl-alt-delor

Không có sự khác biệt nào ... Đôi khi nó không phát hiện ra thử nghiệm đơn vị ... vì vậy nếu bạn mở thử nghiệm và giải pháp xây dựng, nó sẽ đưa ra thử nghiệm đơn vị trong một thời gian ... Có thể bạn đã biết điều đó. ..
Adil

2
Tôi chỉ muốn chắc chắn rằng bạn đang sử dụng một phiên bản cấp tốc hoặc một phiên bản không bao gồm các công cụ kiểm tra. Bạn đã thử cài đặt một người chạy thử bên thứ ba?
Brett Allred

2

Tôi đã tìm ra cách tốt nhất để khắc phục sự cố này là tạo tệp .proj msbuild và thêm các dự án thử nghiệm đơn vị mà bạn gặp sự cố vào tệp này và thực hiện các thử nghiệm bằng phiên bản dòng lệnh của mstest. Tôi đã tìm thấy một sự cố cấu hình nhỏ trong app.config của mình, nó chỉ xuất hiện khi chạy các thử nghiệm từ mstest - nếu không thì dự án thử nghiệm được xây dựng tốt. Ngoài ra, bạn sẽ tìm thấy bất kỳ vấn đề tham khảo gián tiếp với phương pháp này là tốt. Khi bạn có thể chạy thử nghiệm Đơn vị từ dòng lệnh bằng cách sử dụng mstest, sau đó bạn có thể thực hiện một giải pháp sạch, xây dựng lại giải pháp và thử nghiệm của bạn sẽ được phát hiện đúng.


trong trường hợp của tôi, app.config cũng giết chết sự xuất hiện của bài kiểm tra đơn vị. Sau khi xóa app.config và xây dựng lại dự án thử nghiệm, cuối cùng họ đã trở lại!
Chris Richner

2

Trong trường hợp của tôi đó là một cái gì đó khác. Tôi đã cài đặt một gói và sau đó gỡ cài đặt nó và cài đặt lại một phiên bản trước đó. Điều đó đã để lại một configuration/runtime/asssemblyBinding/dependencyIdentitychuyển hướng còn lại trong app.config của tôi. Tôi đã phải sửa nó. Tôi đã tìm ra nó bằng cách nhìn vào Outputcửa sổ và chọn " Tests" trong trình đơn thả xuống. Thông báo lỗi đã có. Đây là một nỗi đau ... Tôi hy vọng nó sẽ giúp người khác.


2

Đây là nhiều hơn để giúp những người kết thúc ở đây hơn là trả lời câu hỏi của OP:

Hãy thử đóng và mở lại studio hình ảnh, đã làm cho tôi mẹo.

Hy vọng điều này sẽ giúp được ai đó.


2

Tôi biết đây là một câu hỏi cũ hơn nhưng với Visual Studio 2015 tôi đã gặp vấn đề trong đó lớp kiểm tra mới tạo của tôi không được công nhận. Đã thử tất cả mọi thứ. Vấn đề cuối cùng là lớp học không được "đưa vào dự án". Tôi chỉ tìm thấy điều này khi khởi động lại Visual Studio và nhận thấy rằng lớp thử nghiệm của tôi không có ở đó. Khi hiển thị các tập tin ẩn, tôi thấy nó, cũng như các lớp khác tôi đã viết, không được bao gồm. Mong rằng sẽ giúp


2

Tôi đã gặp vấn đề này nhiều lần khi tôi cố gắng xây dựng giải pháp trong một PC khác.

Tôi cũng đang sử dụng NUnit và Specflow. Theo mặc định, dự án thử nghiệm của tôi nhắm đến X86 Nhưng tôi phải thay đổi nó thành X64. Các bước là 1. Menu Kiểm tra -> Cài đặt Kiểm tra - Kiến trúc Bộ xử lý Lỗi -> x64. 2. Clean Build 3. Build 4. Nếu các bài kiểm tra vẫn không xuất hiện. 5. Chuyển đến Công cụ Tiện ích mở rộng và cập nhật Sau đó cài đặt thư viện NUnit và Specflow 6. Clean Build 7. Build

Sau đó, thường kiểm tra sẽ xuất hiện trong Test Editor.


@srebella Tốt là bạn đã giải quyết vấn đề này. Tôi đã dành nhiều ngày để giải quyết điều này. Xin chia sẻ kinh nghiệm của bạn với cộng đồng. Vui lòng đặt câu trả lời này lên hàng đầu nếu bạn tin rằng nó hoạt động. Cảm ơn :-)
Shiran Jayawardena

1

Tôi đã cập nhật VS 2012 lên Bản cập nhật mới nhất. tức là cập nhật phòng thu trực quan 3. Điều đó đã khắc phục vấn đề cho tôi.


1

Đối với tôi, giải pháp chỉ phức tạp hơn một chút.

Tôi vừa mới mang một giải pháp hiện có vào máy của mình (được nhân bản từ gitHub) và chúng tôi không theo dõi các tệp .cs được tạo tự động mà Visual Studio đã tạo. (Đối với mỗi tệp tính năng có một tệp .cs có cùng tên)

Mở giải pháp mà không có các tệp .cs liên quan thực sự cho phép tôi điều hướng đến các phương thức bị ràng buộc, vì vậy nó xuất hiện như thể dòng chảy được nối đúng cách, nhưng tôi không thể xem tên thử nghiệm trong Test Explorer.

Đối với vấn đề này, chỉ cần loại trừ các tệp tính năng khỏi dự án và sau đó bao gồm lại chúng, buộc VS phải tạo lại các tệp mã cơ sở được tạo tự động này.

Sau đó, tôi đã có thể xem các thử nghiệm trong trình thám hiểm thử nghiệm.


1

Tôi gặp vấn đề này khi nâng cấp giải pháp của mình từ Microsoft Visual Studio 2012 Express cho Web lên Microsoft Visual Studio 2013.

Tôi đã tạo một dự án Thử nghiệm đơn vị vào năm 2012 và sau khi mở vào năm 2013, dự án Thử nghiệm đơn vị sẽ không hiển thị bất kỳ thử nghiệm nào trong trình thám hiểm thử nghiệm. Mỗi lần tôi thử chạy hoặc gỡ lỗi, nó đều thất bại, nói như sau trong cửa sổ đầu ra:

    Failed to initialize client proxy: 
    could not connect to vstest.discoveryengine.x86.exe

Tôi cũng nhận thấy rằng khi gỡ lỗi các bài kiểm tra, nó đã khởi chạy một phiên bản của Visual Studio 2012. Điều này khiến tôi hiểu rằng dự án Bài kiểm tra đơn vị vẫn đang tham khảo 2012. Nhìn vào tài liệu tham khảo dự án thử nghiệm tôi nhận ra rằng nó đang nhắm mục tiêu sai Microsoft Visual Studio Unit Test Framework DLL cho phiên bản Visual Studio này:

C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll

Tôi đã thay đổi số phiên bản từ 11.0 thành 12.0:

C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll

Tôi đã xây dựng lại tất cả và điều này đã khắc phục vấn đề - tất cả các thử nghiệm đã được tìm thấy trong Test Explorer và bây giờ tất cả các thử nghiệm đều được tìm thấy và chạy hoàn hảo.


1

Kiểm tra xem dự án thử nghiệm của bạn không được đặt thành Chỉ chậm trễ trong thuộc tính dự án của bạn -> Ký. Nếu có, bỏ chọn nó và làm lại sạch sẽ.


hoặc chỉ cần bỏ qua kiểm tra chữ ký trên máy cục bộ của bạn bằng cách sn -Vr *,<public key token>là quản trị viên trong dấu nhắc lệnh của nhà phát triển VS
Silas

1

Tôi gặp vấn đề tương tự trong khi cố gắng mở giải pháp trên một chia sẻ mạng trong VS2013 Ultimate.

Tôi đã khắc phục vấn đề bằng cách bật

Bảng điều khiển -> Tùy chọn Internet -> Tab "Bảo mật" -> Nhấp vào "Mạng nội bộ cục bộ", nhấp vào trang web và đảm bảo "Tự động phát hiện mạng nội bộ" được đánh dấu.


1

Đây là tất cả các câu trả lời tuyệt vời, nhưng có một lý do nữa mà tôi biết; Tôi chỉ chạy vào đó. Trong một trong những thử nghiệm của mình, tôi đã có một tin nhắn ReSharper chỉ ra rằng tôi có một lớp riêng không sử dụng. Đó là một lớp tôi sẽ sử dụng trong một bài kiểm tra sắp tới. Điều này thực sự khiến tất cả các bài kiểm tra của tôi biến mất.


1

Kiểm tra các hội đồng tham chiếu cho bất kỳ hội đồng nào có thể có "Sao chép cục bộ" được đặt thành "Sai".

Nếu dự án thử nghiệm của bạn xây dựng vào thư mục riêng của nó (ví dụ bin / Debug) và dự án phụ thuộc vào một tổ hợp khác và một trong những hội đồng đó trong danh sách Tài liệu tham khảo được đánh dấu Sao chép cục bộ = "Sai", hội đồng không thể tải do thiếu phụ thuộc và bài kiểm tra của bạn sẽ không tải sau khi xây dựng.


1

Có vẻ như NUnit Framework 2.6.4 không hoạt động tốt với NUnit Test Adapter. Trong trang web, nó đề cập đến bộ điều hợp thử nghiệm sẽ chỉ hoạt động với NUnit Framework 2.6.3.

Đây là vấn đề của tôi: 1. Tôi đã tải xuống Bộ điều hợp thử nghiệm NUnit và NUnit riêng biệt thông qua Nuget trong VS2012. Bằng cách nào đó NUnit đã được cập nhật lên 2.6.4 Đột nhiên tôi không thấy các trường hợp thử nghiệm của mình được liệt kê.

Sửa chữa:

  1. Gỡ cài đặt bộ điều hợp Nuget và Nuget Test

    a. Chuyển đến Công cụ> Nuget> Trình quản lý Pug Nuget> Quản lý Nuget Pkg cho Giải pháp

    b. Liệt kê các gói đã cài đặt

    c. Nhấp vào quản lý

    d. Bỏ kiểm tra dự án của bạn

  2. Cài đặt Bộ điều hợp thử nghiệm NUnit bao gồm Khung NUnit 2.6.3

  3. Giải pháp làm sạch / xây dựng lại

  4. Mở Test> Test Explorer> Chạy tất cả

Tôi thấy tất cả các trường hợp thử nghiệm

Hi vọng điêu nay co ich


1

Không có giải pháp nào ở đây giúp tôi. Các thử nghiệm sẽ không được phát hiện cho một giải pháp trong khi một giải pháp khác tham khảo cùng các dự án hoạt động tốt. Cuối cùng tôi đã giải quyết điều này bằng cách xóa tệp Solutionname.v12.suo.


1

Tôi đã có cùng một vấn đề, nhưng một chút khác nhau.

Tôi đã sử dụng visual studio 2012. Vì một số lý do, chỉ có các bài kiểm tra của tệp được tạo ban đầu đang chạy. Nhưng các bài kiểm tra trong một tập tin khác đã không chạy. Đã thử các giải pháp khác nhau được đăng ở đây, không hoạt động.

Cuối cùng tôi đã tìm ra rằng tôi có một phương thức riêng trong lớp kiểm tra, đó là phương thức đầu tiên trong lớp. Tôi chỉ di chuyển phương thức riêng tư sau một phương pháp thử nghiệm; vì vậy bây giờ, một phương thức với [TestMethod]thuộc tính là phương thức đầu tiên bên trong lớp. Lạ, nhưng bây giờ nó hoạt động.

Hy vọng điều này sẽ giúp ai đó một ngày nào đó.


1

Các thử nghiệm không thích các phương pháp async. Ví dụ:

    [TestMethod]
    public async void TestMethod1()
    {
        TestLib oLib = new TestLib();
        var bTest = await oLib.Authenticate();

    }

Sau khi làm điều này:

    [TestMethod]
    public void TestAuth()
    {
        TestMethod1();
    }

    public async void TestMethod1()
    {
        TestLib oLib = new TestLib();
        var bTest = await oLib.Authenticate();

    }

Nó đã thấy bài kiểm tra.


Một câu trả lời tốt hơn là[Test] public void XamarinExampleTest() { // This workaround is necessary on Xamarin, // which doesn't support async unit test methods. Task.Run(async () => { // Actual test code here. }).GetAwaiter().GetResult(); }
Robert Green MBA

3
"Các thử nghiệm không thích các phương thức async "sai . "Các thử nghiệm không thích các phương thức void async "đúng và giải pháp chỉ đơn giản là khai báo một phương thức thử nghiệm dưới dạng Nhiệm vụ async .
Massimiliano Kraus

1

Thêm câu trả lời của tôi vì đây là kết quả hàng đầu trên Google cho việc này.

Tôi đang sử dụng Visual Studio 2015 và (vô tình - tôi vừa chạy Install-Package NUnit) đã cài đặt gói NUnit3 NuGet cho dự án thử nghiệm của tôi. Tôi đã cài đặt tiện ích mở rộng Bộ điều hợp thử nghiệm NUnit và các thử nghiệm của tôi vẫn không hiển thị.

Cài đặt Bộ điều hợp thử nghiệm NUnit3 thông qua Công cụ> Tiện ích mở rộng và Cập nhật đã sửa lỗi này cho tôi.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.