Làm thế nào để bạn đơn vị kiểm tra một bộ mã hóa?

Tôi có một cái gì đó như thế này:

public byte[] EncodeMyObject(MyObject obj)

Tôi đã từng thử nghiệm đơn vị như thế này:

byte[] expectedResults = new byte[3]{ 0x01, 0x02, 0xFF };
Assert.IsEqual(expectedResults, EncodeMyObject(myObject));

EDIT: Hai cách tôi đã thấy đề xuất là:

1) Sử dụng các giá trị dự kiến ​​được mã hóa cứng, như ví dụ trên.

2) Sử dụng bộ giải mã để giải mã mảng byte được mã hóa và so sánh các đối tượng đầu vào / đầu ra.

Vấn đề tôi thấy với phương pháp 1 là nó rất dễ vỡ và đòi hỏi nhiều giá trị được mã hóa cứng.

Vấn đề với phương pháp 2 là việc kiểm tra bộ mã hóa phụ thuộc vào bộ giải mã hoạt động chính xác. Nếu bộ mã hóa / giải mã bị phá vỡ bằng nhau (ở cùng một vị trí), thì các thử nghiệm có thể tạo ra kết quả dương tính giả.

Đây rất có thể là những cách duy nhất để kiểm tra loại phương pháp này. Nếu đó là trường hợp tốt. Tôi đang đặt câu hỏi để xem liệu có chiến lược nào tốt hơn cho loại thử nghiệm này không. Tôi không thể tiết lộ nội bộ của bộ mã hóa cụ thể mà tôi đang làm việc. Tôi đang hỏi nói chung làm thế nào bạn sẽ giải quyết loại vấn đề này và tôi không cảm thấy nội bộ là quan trọng. Giả sử rằng một đối tượng đầu vào đã cho sẽ luôn tạo ra cùng một mảng byte đầu ra.

Bạn đang ở trong một tình huống đáng ghét ở đó. Nếu bạn có một định dạng tĩnh mà bạn đã mã hóa thành, phương pháp đầu tiên của bạn sẽ là cách để đi. Nếu đó chỉ là định dạng của riêng bạn và không ai khác phải giải mã hơn phương thức thứ hai sẽ là cách để đi. Nhưng bạn không thực sự phù hợp với một trong những loại đó.

Những gì tôi sẽ làm là cố gắng phá vỡ mọi thứ theo mức độ trừu tượng.

Vì vậy, tôi bắt đầu với một cái gì đó ở cấp độ bit, rằng tôi sẽ thử nghiệm một cái gì đó như

bitWriter = new BitWriter();
bitWriter.writeInt(42, bits = 7);
assertEqual( bitWriter.data(), {0x42} )

Vì vậy, ý tưởng là bitwriter biết cách viết ra các loại trường nguyên thủy nhất, như ints.

Các loại phức tạp hơn sẽ được triển khai bằng cách sử dụng và thử nghiệm một cái gì đó như:

bitWriter = new BitWriter();
writeDate(bitWriter, new Datetime(2001, 10, 4));

bitWriter2 = new BitWriter();
bitWriter2.writeInt(2001, 12)
bitWriter2.writeInt(10, 4)
bitWriter2.writeInt(4, 6)

assertEquals(bitWriter.data(), bitWriter2.data() )

Lưu ý rằng điều này tránh mọi kiến ​​thức về cách các bit thực tế được đóng gói. Điều đó đã được thử nghiệm bởi thử nghiệm trước đó và đối với thử nghiệm này, chúng tôi gần như sẽ cho rằng nó hoạt động.

Sau đó, ở mức độ trừu tượng tiếp theo, chúng ta sẽ có

bitWriter = new BitWriter();
encodeObject(bitWriter, myObject);


bitWriter2 = new BitWriter();
bitWriter2.writeInt(42, 32)
writeDate(bitWriter2, new Datetime(2001, 10, 4));
writeVarString(bitWriter2, "alphanumeric");

assertEquals(bitWriter.data(), bitWriter2.data() )

vì vậy, một lần nữa, chúng tôi không cố gắng đưa vào kiến ​​thức về cách các biến số hoặc ngày hoặc số thực sự được mã hóa. Trong thử nghiệm này, chúng tôi chỉ quan tâm đến việc mã hóa được tạo bởi encodeObject.

Kết quả cuối cùng là nếu định dạng ngày thay đổi, bạn sẽ phải sửa các bài kiểm tra thực sự liên quan đến ngày, nhưng tất cả các mã và bài kiểm tra khác không liên quan đến cách ngày thực sự được mã hóa và một khi bạn cập nhật mã để thực hiện công việc đó, tất cả những bài kiểm tra sẽ vượt qua tốt

Phụ thuộc. Nếu mã hóa là một cái gì đó hoàn toàn cố định, trong đó mọi thực hiện được cho là tạo ra chính xác cùng một đầu ra, thì sẽ không có ý nghĩa gì khi kiểm tra bất cứ thứ gì ngoài việc xác minh ví dụ đầu vào ánh xạ tới chính xác các đầu ra dự kiến. Đó là bài kiểm tra rõ ràng nhất, và có lẽ cũng dễ viết nhất.

Nếu có phòng ngọ nguậy với đầu ra thay thế, như trong tiêu chuẩn MPEG (ví dụ: có một số toán tử nhất định bạn có thể áp dụng cho đầu vào, nhưng bạn có thể tự do đánh đổi nỗ lực mã hóa so với chất lượng đầu ra hoặc không gian lưu trữ), thì tốt hơn nên áp dụng chiến lược giải mã được xác định cho đầu ra và xác minh rằng nó giống với đầu vào - hoặc, nếu mã hóa bị mất, nó gần hợp lý với đầu vào ban đầu. Điều đó khó lập trình hơn, nhưng bảo vệ bạn trước mọi cải tiến trong tương lai có thể được thực hiện cho bộ mã hóa của bạn.

Kiểm tra điều đó encode(decode(coded_value)) == coded_valuevà decode(encode(value)) == value. Bạn có thể cung cấp một đầu vào ngẫu nhiên cho các bài kiểm tra nếu bạn muốn.

Vẫn có khả năng cả bộ mã hóa và bộ giải mã đều bị hỏng theo những cách miễn phí, nhưng điều đó dường như khá khó xảy ra trừ khi bạn có sự hiểu lầm về khái niệm của tiêu chuẩn mã hóa. Thực hiện các bài kiểm tra mã hóa cứng của bộ mã hóa và bộ giải mã (như bạn đã làm) sẽ bảo vệ chống lại điều đó.

Nếu bạn có quyền truy cập vào một triển khai khác mà công việc này được biết là hoạt động, ít nhất bạn có thể sử dụng nó để có được sự tin tưởng rằng việc triển khai của bạn là tốt ngay cả khi sử dụng nó trong các bài kiểm tra đơn vị là không thể.

Kiểm tra theo yêu cầu .

Nếu các yêu cầu chỉ là 'mã hóa thành luồng byte mà khi được giải mã sẽ tạo ra một đối tượng tương đương.', Thì chỉ cần kiểm tra bộ mã hóa bằng cách giải mã. Nếu bạn đang viết cả bộ mã hóa và bộ giải mã, thì chỉ cần kiểm tra chúng cùng nhau. Họ không thể có "lỗi khớp". Nếu họ làm việc cùng nhau, sau đó thử nghiệm vượt qua.

Nếu có các yêu cầu khác cho luồng dữ liệu, thì bạn sẽ phải kiểm tra chúng bằng cách kiểm tra dữ liệu được mã hóa.

Nếu định dạng được mã hóa được xác định trước, thì bạn sẽ phải xác minh dữ liệu được mã hóa theo kết quả mong đợi, như bạn đã làm, hoặc (tốt hơn) có được bộ giải mã tham chiếu có thể tin cậy để thực hiện xác minh. Việc sử dụng bộ giải mã tham chiếu giúp loại bỏ khả năng bạn đã hiểu sai đặc tả định dạng.

Tùy thuộc vào khung thử nghiệm và mô hình bạn đang sử dụng, bạn vẫn có thể sử dụng mẫu Sắp xếp xác nhận hành động cho việc này như bạn đã nói.

[TestMethod]
public void EncodeMyObject_ForValidInputs_Encodes()
{
    //Arrange object under test
    MyEncoder encoderUnderTest = new MyEncoder();
    MyObject validObject = new MyOjbect();
    //arrange object for condition under test

    //Act
    byte[] actual = encoderUnderTest.EncodeMyObject(myObject);

    //Assert
    byte[] expected = new byte[3]{ 0x01, 0x02, 0xFF };
    Assert.IsEqual(expected, actual);
}

Bạn nên biết các yêu cầu EncodeMyObject()và có thể sử dụng mẫu này để kiểm tra từng tiêu chí cho các tiêu chí hợp lệ và không hợp lệ, bằng cách sắp xếp từng trong số chúng và mã hóa kết quả mong đợi expected, tương tự cho bộ giải mã.

Vì dự kiến ​​được mã hóa cứng, chúng sẽ dễ vỡ nếu bạn có một thay đổi lớn.

Bạn có thể tự động hóa với một cái gì đó được điều khiển bởi tham số (hãy xem Pex ) hoặc nếu bạn đang làm DDD hoặc BDD hãy xem gerkin / dưa chuột .

Bạn có thể quyết định điều gì là quan trọng với bạn.

Điều quan trọng với bạn là một Vật thể sống sót sau chuyến đi khứ hồi và định dạng dây chính xác không thực sự quan trọng? Hoặc định dạng dây chính xác là một phần quan trọng của chức năng của bộ mã hóa và giải mã của bạn?

Nếu trước đây, hơn là chỉ đảm bảo rằng các đối tượng sống sót trong chuyến đi khứ hồi. Nếu cả bộ mã hóa và bộ giải mã đều bị hỏng theo những cách bổ sung chính xác, bạn không thực sự quan tâm.

Nếu sau này, thì bạn cần phải kiểm tra định dạng dây như bạn mong đợi cho các đầu vào đã cho. Điều này có nghĩa là kiểm tra định dạng trực tiếp hoặc bằng cách khác sử dụng triển khai tham chiếu. Nhưng khi đã kiểm tra những điều cơ bản, bạn có thể nhận được giá trị từ các bài kiểm tra khứ hồi bổ sung, việc viết khối lượng sẽ dễ dàng hơn.