ข้อตกลงการตั้งชื่อยอดนิยมสำหรับการทดสอบหน่วยมีอะไรบ้าง [ปิด]

ทั่วไป

• ปฏิบัติตามมาตรฐานเดียวกันสำหรับการทดสอบทั้งหมด
• ชัดเจนเกี่ยวกับสถานะการทดสอบแต่ละครั้ง
• มีความเฉพาะเจาะจงเกี่ยวกับพฤติกรรมที่คาดหวัง

ตัวอย่าง

1) MethodName_StateUnderTest_ExpectedBehavior

Public void Sum_NegativeNumberAs1stParam_ExceptionThrown() 

Public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () 

Public void Sum_simpleValues_Calculated ()

ที่มา: การตั้งชื่อมาตรฐานสำหรับการทดสอบหน่วย

2) การแยกแต่ละคำด้วยการขีดเส้นใต้

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 ()

อื่น ๆ

• สิ้นสุดชื่อวิธีด้วยการทดสอบ
• เริ่มต้นชื่อเมธอดพร้อมชื่อคลาส

ฉันสวยมากกับคุณกับผู้ชายคนนี้ แบบแผนการตั้งชื่อที่คุณใช้คือ:

• ชัดเจนเกี่ยวกับสถานะการทดสอบแต่ละรายการ
• โดยเฉพาะเกี่ยวกับพฤติกรรมที่คาดหวัง

คุณต้องการอะไรอีกจากชื่อการทดสอบ

ตรงกันข้ามกับคำตอบของ Rayฉันไม่คิดว่าจำเป็นต้องมีคำนำหน้าการทดสอบ มันเป็นรหัสทดสอบเรารู้ว่า หากคุณจำเป็นต้องทำเช่นนี้เพื่อระบุรหัสจากนั้นคุณมีปัญหามากขึ้นรหัสทดสอบของคุณไม่ควรผสมกับรหัสการผลิตของคุณ

สำหรับความยาวและการใช้ขีดเส้นใต้รหัสทดสอบของมันใครจะสนใจ? มีเพียงคุณและทีมของคุณเท่านั้นที่จะเห็นมันตราบใดที่มันสามารถอ่านได้และชัดเจนเกี่ยวกับสิ่งที่ทำแบบทดสอบดำเนินต่อไป! :)

ที่กล่าวว่าฉันยังค่อนข้างใหม่ในการทดสอบและบล็อกการผจญภัยของฉันด้วย :)

นี่เป็นสิ่งที่ควรอ่าน: การทดสอบโครงสร้างหน่วย

โครงสร้างมีคลาสทดสอบต่อคลาสที่กำลังทดสอบ นั่นไม่ใช่เรื่องแปลก แต่สิ่งที่แปลกสำหรับฉันก็คือเขามีคลาสที่ซ้อนกันสำหรับแต่ละวิธีที่กำลังทดสอบ

เช่น

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
        }
    }
}

และนี่คือเหตุผล:

สำหรับสิ่งหนึ่งมันเป็นวิธีที่ดีในการจัดระเบียบการทดสอบ การทดสอบทั้งหมด (หรือข้อเท็จจริง) สำหรับวิธีการจะจัดกลุ่มเข้าด้วยกัน ตัวอย่างเช่นหากคุณใช้ช็อตคัต CTRL + M, CTRL + O เพื่อย่อส่วนของเมธอดคุณสามารถสแกนการทดสอบและอ่านได้อย่างง่ายดายเช่น spec สำหรับรหัสของคุณ

ฉันชอบวิธีนี้:

MethodName_StateUnderTest_ExpectedBehavior

ดังนั้นอาจปรับเป็น:

StateUnderTest_ExpectedBehavior

เพราะการทดสอบแต่ละครั้งจะอยู่ในชั้นซ้อนกันแล้ว

ฉันมักจะใช้แบบแผนของMethodName_DoesWhat_WhenTheseConditionsตัวอย่างเช่น:

Sum_ThrowsException_WhenNegativeNumberAs1stParam

อย่างไรก็ตามสิ่งที่ฉันเห็นมากคือการทำให้ชื่อการทดสอบเป็นไปตามโครงสร้างการทดสอบหน่วยของ

• เตรียมการ
• การกระทำ
• ยืนยัน

ซึ่งยังติดตามไวยากรณ์ BDD / Gherkin ของ:

• ป.ร. ให้ไว้
• เมื่อไหร่
• แล้วก็

ซึ่งจะตั้งชื่อการทดสอบในลักษณะของ: UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

ตัวอย่างของคุณ:

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

อย่างไรก็ตามฉันชอบที่จะใส่ชื่อเมธอดที่จะทดสอบก่อนเพราะการทดสอบนั้นสามารถจัดเรียงตามตัวอักษรหรือเรียงตามลำดับตัวอักษรในกล่องดรอปดาวน์สมาชิกใน VisStudio และการทดสอบทั้งหมดสำหรับ 1 วิธีจะถูกจัดกลุ่มเข้าด้วยกัน

ไม่ว่าในกรณีใดฉันชอบแยกส่วนสำคัญของชื่อทดสอบด้วยเครื่องหมายขีดล่างตรงข้ามกับคำทุกคำเพราะฉันคิดว่ามันช่วยให้อ่านและเข้าใจจุดทดสอบได้ง่ายขึ้น

ในคำอื่น ๆ ผมชอบ: ดีกว่าSum_ThrowsException_WhenNegativeNumberAs1stParamSum_Throws_Exception_When_Negative_Number_As_1st_Param

ฉันตั้งชื่อวิธีการทดสอบของฉันเหมือนกับวิธีอื่น ๆ โดยใช้ "PascalCasing" โดยไม่มีขีดเส้นใต้หรือตัวคั่น ฉันออกจากการทดสอบ postfix สำหรับวิธีการออกเพราะมันไม่มีค่าเพิ่ม ว่าวิธีการที่เป็นวิธีการทดสอบจะถูกระบุด้วยแอตทริบิวต์TestMethod

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

เนื่องจากข้อเท็จจริงที่ว่าแต่ละคลาสการทดสอบควรทดสอบคลาสอื่นเท่านั้นฉันปล่อยให้ชื่อของคลาสออกจากชื่อวิธี ชื่อของคลาสที่มีเมธอดการทดสอบมีชื่อเหมือนกับคลาสที่อยู่ภายใต้การทดสอบด้วย postfix "Tests"

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

สำหรับวิธีการที่การทดสอบสำหรับข้อยกเว้นหรือการกระทำที่ไม่เป็นไปได้ผมคำนำหน้าวิธีการทดสอบที่มีคำว่าไม่สามารถ

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

ความเชื่อมั่นในการตั้งชื่อของฉันอยู่ที่บทความ"เคล็ดลับ TDD: แบบทดสอบการตั้งชื่อและแนวทาง"ของ Bryan Cook ฉันพบบทความนี้มีประโยชน์มาก

ชุดแรกของชื่อสามารถอ่านได้มากขึ้นสำหรับฉันเนื่องจาก CamelCasing แยกคำและแถบใต้ส่วนต่าง ๆ ของแผนการตั้งชื่อ

ฉันมักจะรวม "ทดสอบ" ที่ใดที่หนึ่งไม่ว่าจะเป็นในชื่อฟังก์ชั่นหรือล้อมรอบเนมสเปซหรือคลาส

ตราบใดที่คุณทำตามการฝึกฝนเพียงครั้งเดียวมันก็ไม่สำคัญ โดยทั่วไปฉันเขียนการทดสอบหน่วยเดียวสำหรับวิธีการที่ครอบคลุมการเปลี่ยนแปลงทั้งหมดสำหรับวิธีการ (ฉันมีวิธีการง่าย ๆ ) แล้วเขียนชุดการทดสอบที่ซับซ้อนมากขึ้นสำหรับวิธีการที่ต้องการ โครงสร้างการตั้งชื่อของฉันจึงมักจะทดสอบ (โฮลด์จาก JUnit 3)

ฉันใช้คำนำหน้า 'T' สำหรับการทดสอบเนมสเปซ, คลาสและเมธอด

ฉันพยายามเรียบร้อยและสร้างโฟลเดอร์ที่ทำซ้ำเนมสเปซจากนั้นสร้างโฟลเดอร์การทดสอบหรือโปรเจ็กต์แยกต่างหากสำหรับการทดสอบและทำซ้ำโครงสร้างการผลิตสำหรับการทดสอบพื้นฐาน:

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

ฉันสามารถเห็นได้อย่างง่ายดายว่ามีการทดสอบอะไรฉันรู้แน่ชัดว่ารหัสต้นฉบับนั้นเกี่ยวข้องกับอะไร (ถ้าคุณไม่สามารถทำงานออกมาได้การทดสอบก็ซับซ้อนเกินไป)

ดูเหมือนว่ารูปแบบการตั้งชื่ออินเทอร์เฟซ (ฉันหมายถึงคุณจะไม่สับสนกับสิ่งที่เริ่มต้นด้วย 'ฉัน' และคุณจะไม่ใช้ 'T')

ง่ายในการรวบรวมโดยมีหรือไม่มีการทดสอบ

ในทางทฤษฎีแล้วมันใช้ได้ดีสำหรับโครงการขนาดเล็ก