Một số quy ước đặt tên phổ biến cho các bài kiểm tra đơn vị là gì? [đóng cửa]

Chung

• Thực hiện theo các tiêu chuẩn giống nhau cho tất cả các bài kiểm tra.
• Hãy rõ ràng về từng trạng thái thử nghiệm.
• Hãy cụ thể về hành vi dự kiến.

Ví dụ

1) Phương thứcName_StateUnderTest_ExpectedBehavior

Public void Sum_NegativeNumberAs1stParam_ExceptionThrown() 

Public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () 

Public void Sum_simpleValues_Calculated ()

Nguồn: Đặt tên tiêu chuẩn cho bài kiểm tra đơn vị

2) Tách từng từ bằng cách gạch dưới

Public void Sum_Negative_Number_As_1st_Param_Exception_Thrown() 

Public void Sum_Negative_Number_As_2nd_Param_Exception_Thrown () 

Public void Sum_Simple_Values_Calculated ()

Khác

• Kết thúc tên phương thức với Test
• Bắt đầu tên phương thức với tên lớp

Tôi khá nhiều với bạn về người đàn ông này. Các quy ước đặt tên bạn đã sử dụng là:

• Rõ ràng về từng trạng thái thử nghiệm là gì.
• Cụ thể về hành vi dự kiến.

Bạn cần thêm gì từ một tên thử nghiệm?

Trái với câu trả lời của Ray, tôi không nghĩ tiền tố Test là cần thiết. Đó là mã kiểm tra, chúng tôi biết rằng. Nếu bạn cần làm điều này để xác định mã, thì bạn có vấn đề lớn hơn, mã kiểm tra của bạn không nên trộn lẫn với mã sản xuất của bạn.

Đối với chiều dài và sử dụng dấu gạch dưới, mã thử nghiệm của nó , ai sẽ quan tâm? Chỉ có bạn và nhóm của bạn sẽ nhìn thấy nó, miễn là có thể đọc được, và rõ ràng về những gì bài kiểm tra đang làm, tiếp tục! :)

Điều đó nói rằng, tôi vẫn còn khá mới để thử nghiệm và viết blog những cuộc phiêu lưu của tôi với nó :)

Điều này cũng đáng để đọc: Kiểm tra đơn vị cấu trúc

Cấu trúc có một lớp kiểm tra cho mỗi lớp đang được kiểm tra. Điều đó không quá bất thường. Nhưng điều bất thường với tôi là anh ta có một lớp lồng cho mỗi phương thức đang được thử nghiệm.

ví dụ

using Xunit;

public class TitleizerFacts
{
    public class TheTitleizerMethod
    {
        [Fact]
        public void NullName_ReturnsDefaultTitle()
        {
            // Test code
        }

        [Fact]
        public void Name_AppendsTitle()
        {
            // Test code
        }
    }

    public class TheKnightifyMethod
    {
        [Fact]
        public void NullName_ReturnsDefaultTitle()
        {
            // Test code
        }

        [Fact]
        public void MaleNames_AppendsSir()
        {
            // Test code
        }

        [Fact]
        public void FemaleNames_AppendsDame()
        {
            // Test code
        }
    }
}

Và đây là lý do:

Đối với một điều, đó là một cách tốt đẹp để tổ chức các bài kiểm tra. Tất cả các bài kiểm tra (hoặc sự kiện) cho một phương pháp được nhóm lại với nhau. Ví dụ: nếu bạn sử dụng phím tắt CTRL + M, CTRL + O để thu gọn các thân phương thức, bạn có thể dễ dàng quét các bài kiểm tra của mình và đọc chúng như một thông số kỹ thuật cho mã của bạn.

Tôi cũng thích cách tiếp cận này:

Phương thứcName_StateUnderTest_ExpectedBehavior

Vì vậy, có lẽ điều chỉnh để:

StateUnderTest_ExpectedBehavior

Bởi vì mỗi bài kiểm tra sẽ có trong một lớp lồng nhau

Tôi có xu hướng sử dụng quy ước MethodName_DoesWhat_WhenTheseConditionsnhư vậy, ví dụ:

Sum_ThrowsException_WhenNegativeNumberAs1stParam

Tuy nhiên, điều tôi thấy rất nhiều là làm cho tên thử nghiệm tuân theo cấu trúc thử nghiệm đơn vị của

• Sắp xếp
• Đạo luật
• Khẳng định

Điều này cũng tuân theo cú pháp BDD / Gherkin của:

• Được
• Khi nào
• Sau đó

sẽ đặt tên cho bài kiểm tra theo cách: UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

ví dụ của bạn

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

Tuy nhiên, tôi rất thích đặt tên phương thức được kiểm tra trước, vì sau đó các bài kiểm tra có thể được sắp xếp theo thứ tự bảng chữ cái hoặc xuất hiện theo thứ tự bảng chữ cái trong hộp thả xuống thành viên trong VisStudio và tất cả các bài kiểm tra cho 1 phương thức được nhóm lại với nhau.

Trong mọi trường hợp, tôi thích tách các phần chính của tên kiểm tra với dấu gạch dưới, trái với mọi từ , bởi vì tôi nghĩ nó giúp đọc và lấy điểm của bài kiểm tra dễ dàng hơn.

Nói cách khác, tôi thích: Sum_ThrowsException_WhenNegativeNumberAs1stParamtốt hơn Sum_Throws_Exception_When_Negative_Number_As_1st_Param.

Tôi đặt tên cho các phương thức thử nghiệm của mình giống như các phương thức khác bằng cách sử dụng "PascalCasing" mà không có bất kỳ dấu gạch dưới hoặc dấu phân cách nào. Tôi bỏ bài kiểm tra postfix cho phương thức ra, vì nó không thêm giá trị. Phương thức này là một phương thức thử nghiệm được chỉ định bởi thuộc tính TestMethod .

[TestMethod]
public void CanCountAllItems() {
  // Test the total count of items in collection.
}

Do thực tế là mỗi lớp Test chỉ nên kiểm tra một lớp khác, tôi để tên của lớp ngoài tên phương thức. Tên của lớp chứa các phương thức kiểm tra được đặt tên giống như lớp được kiểm tra với hậu tố "Kiểm tra".

[TestClass]
public class SuperCollectionTests(){
    // Any test methods that test the class SuperCollection
}

Đối với các phương thức kiểm tra ngoại lệ hoặc hành động không thể thực hiện được, tôi đặt tiền tố phương thức kiểm tra bằng từ Không thể .

[TestMethod]
[ExpectedException(typeOf(ArgumentException))]
public void CannotAddSameObjectAgain() {
  // Cannot add the same object again to the collection.
}

Sự tin tưởng đặt tên của tôi dựa trên bài viết "Mẹo TDD: Kiểm tra các quy ước và hướng dẫn đặt tên" của Bryan Cook. Tôi thấy bài viết này rất hữu ích.

Nhóm tên đầu tiên dễ đọc hơn đối với tôi, vì CamelCasing phân tách các từ và phần dưới của các phần riêng biệt của sơ đồ đặt tên.

Tôi cũng có xu hướng bao gồm "Kiểm tra" ở đâu đó, trong tên hàm hoặc không gian tên kèm theo hoặc lớp.

Miễn là bạn tuân theo một thực hành duy nhất, nó không thực sự quan trọng. Nói chung, tôi viết một thử nghiệm đơn vị cho một phương thức bao gồm tất cả các biến thể cho một phương thức (tôi có các phương thức đơn giản;) và sau đó viết các bộ thử nghiệm phức tạp hơn cho các phương thức yêu cầu nó. Cấu trúc đặt tên của tôi do đó thường là thử nghiệm (một sự nắm giữ từ JUnit 3).

Tôi sử dụng tiền tố 'T' cho các không gian tên, lớp và phương thức thử nghiệm.

Tôi cố gắng gọn gàng và tạo các thư mục sao chép các không gian tên, sau đó tạo một thư mục thử nghiệm hoặc dự án riêng cho các thử nghiệm và sao chép cấu trúc sản xuất cho các thử nghiệm cơ bản:

AProj
   Objects
      AnObj
         AProp
   Misc
      Functions
         AFunc
   Tests
      TObjects
         TAnObj
            TAnObjsAreEqualUnderCondition
      TMisc
         TFunctions
            TFuncBehavesUnderCondition

Tôi có thể dễ dàng thấy rằng một cái gì đó là một thử nghiệm, tôi biết chính xác mã gốc mà nó liên quan đến là gì (nếu bạn không thể làm được điều đó, thì dù sao thì thử nghiệm đó cũng quá phức tạp).

Nó trông giống như quy ước đặt tên giao diện, (ý tôi là, bạn không bị nhầm lẫn với những thứ bắt đầu bằng 'Tôi', cũng như bạn với 'T').

Thật dễ dàng để chỉ biên dịch có hoặc không có các bài kiểm tra.

Dù sao thì nó cũng tốt về mặt lý thuyết và hoạt động khá tốt cho các dự án nhỏ.