Tôi đang cố gắng kiểm tra đơn vị chức năng riêng tư trong .net. Hàm riêng này trả về một tập hợp kiểu myClass, là một lớp nội bộ.InternalsVisibleTo có vẻ bị bỏ qua
Tôi đã sử dụng thuộc tính assembly InternalsVisibleTo, để loại myClass được biết đến với dự án Thử nghiệm của tôi.
Dưới đây là đoạn code tôi muốn thử nghiệm:
namespace MyProject
{
public class Class1
{
private List<myClass> myFunction()
{
return new List<myClass>();
}
internal class myClass
{
public int MyProperty { get; set; }
}
}
}
[TestMethod()]
[DeploymentItem("MyProject.dll")]
public void myFunctionTest()
{
Class1_Accessor target = new Class1_Accessor();
List<Class1_Accessor.myClass> expected = null;
List<Class1_Accessor.myClass> actual;
actual = target.myFunction();
Assert.AreEqual(expected, actual);
Assert.Inconclusive("Verify the correctness of this test method.");
}
và thông tin lắp ráp tập tin của tôi:
[assembly: InternalsVisibleTo("MyProject.Test")]
Vậy tại sao Visual Studio thiết lập các loại danh sách để Class1_Accessor.myClass từ myClass là biết cho dự án thử nghiệm của tôi?
Do đó tôi gặp lỗi thời gian chạy (không thể chuyển đổi loại myClass thành loại Class1_Accessor.myClass).
Vì myFunction là tư nhân, VisualStudio tạo ra đoạn mã sau (đó là tốt cho hầu hết của nó)
[Shadowing("MyProject.Class1")]
public class Class1_Accessor : BaseShadow
{
protected static PrivateType m_privateType;
[Shadowing("[email protected]")]
public Class1_Accessor();
public Class1_Accessor(PrivateObject value);
public static PrivateType ShadowedType { get; }
public static Class1_Accessor AttachShadow(object value);
[Shadowing("[email protected]")]
public List<Class1_Accessor.myClass> myFunction();
[Shadowing("MyProject.Class1+myClass")]
public class myClass : BaseShadow
{
protected static PrivateType m_privateType;
[Shadowing("[email protected]")]
public myClass();
public myClass(PrivateObject value);
[Shadowing("MyProperty")]
public int MyProperty { get; set; }
public static PrivateType ShadowedType { get; }
public static Class1_Accessor.myClass AttachShadow(object value);
}
}
Tuy nhiên, tôi không hiểu tại sao nó có chứa một định nghĩa mới của myClass, vì nó là một lớp nội bộ, không cần bất kỳ người truy cập nào. Đây là gốc rễ của vấn đề trong quan điểm của tôi.
Bạn có thể muốn thêm thẻ 'mstest' để thu hút sự chú ý của những người có kinh nghiệm sử dụng Accessors. Tôi không chắc chắn nên xóa thẻ nào, vì vậy tôi không tự chỉnh sửa thẻ. Tôi không bao giờ quan tâm nhiều đến những người truy cập, vì vậy tôi có ít kinh nghiệm. (Hơn nữa, có một tình cảm mạnh mẽ rằng bạn không nên thử nghiệm các thành viên riêng tư, nếu bạn có một thành viên riêng không thể kiểm tra gián tiếp thông qua một công chúng, thì đó là dấu hiệu cho thấy bạn nên trích xuất một lớp riêng biệt cho logic đó.) – phoog
cảm ơn , Tôi đã thêm thẻ. Kiểm tra các thành viên tư nhân hay không là một chủ đề hoàn toàn khác (mặc dù bạn là đúng). Tuy nhiên, tôi vẫn muốn thử nghiệm một chức năng đó. – Sam
Về thử nghiệm của các thành viên tư nhân, thực tế là nó là một chủ đề hoàn toàn khác nhau là lý do tôi đặt nó trong ngoặc đơn. Và tất nhiên, luôn có những ngoại lệ có thể bảo vệ được với các nguyên tắc như vậy. Tôi sẽ thêm rằng khi tôi * có * thử nghiệm các thành viên riêng tư, tôi thường chỉ sử dụng sự phản chiếu - tôi thậm chí còn có một số phương thức trợ giúp cho mục đích (ví dụ: 'CallNonPublicMethod (string methodName)'). Tôi thấy rằng dễ dàng hơn để đối phó với các accessors - Tôi không bao giờ tìm ra cách để có được chúng tái sinh khi tôi sửa đổi các lớp họ đã shadowing. – phoog