ควรเป็น "จัด - ยืนยัน - กระทำ - ยืนยัน" หรือไม่

เกี่ยวกับรูปแบบการทดสอบแบบคลาสสิกของArrange-Act-Assertฉันมักพบว่าตัวเองมีการเพิ่มการยืนยันตัวตนที่มาก่อนพระราชบัญญัติ วิธีนี้ทำให้ฉันรู้ว่าการยืนยันที่ผ่านนั้นผ่านไปแล้วอันเป็นผลมาจากการกระทำ

ฉันคิดว่ามันคล้ายคลึงกับสีแดงในตัวปรับปฏิกิริยาสีแดง - เขียวซึ่งถ้าฉันเห็นแถบสีแดงในระหว่างการทดสอบเท่านั้นฉันจะรู้ว่าแถบสีเขียวหมายถึงฉันได้เขียนโค้ดที่สร้างความแตกต่าง ถ้าฉันเขียนแบบทดสอบที่ผ่านรหัสใด ๆก็จะตอบสนองได้ ในทำนองเดียวกันในส่วนของการจัดเตรียม - การยืนยัน - การกระทำ - การยืนยันหากการยืนยันครั้งแรกของฉันล้มเหลวฉันรู้ว่าพระราชบัญญัติใด ๆ จะผ่านการยืนยันขั้นสุดท้าย - ดังนั้นจึงไม่ได้ตรวจสอบอะไรเกี่ยวกับพระราชบัญญัติ

การทดสอบของคุณเป็นไปตามรูปแบบนี้หรือไม่ ทำไมหรือทำไมไม่?

การชี้แจงการอัปเดต : การยืนยันครั้งแรกนั้นตรงกันข้ามกับการยืนยันขั้นสุดท้าย ไม่ใช่การยืนยันว่าการจัดเรียงใช้ได้ผล เป็นการยืนยันว่าพระราชบัญญัติยังไม่ได้ผล

นี่ไม่ใช่สิ่งที่ต้องทำบ่อยที่สุด แต่ก็ยังมีชื่อเป็นของตัวเอง เทคนิคนี้เรียกว่ายามยืนยัน คุณสามารถดูคำอธิบายโดยละเอียดได้ในหน้า 490 ในหนังสือที่ยอดเยี่ยมxUnit Test Patternsโดย Gerard Meszaros (ขอแนะนำ)

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

อาจมีเงื่อนไขเบื้องต้นหลายประการที่ต้องปฏิบัติตามสำหรับกรณีทดสอบที่กำหนดดังนั้นคุณอาจต้องใช้ Guard Assertion มากกว่าหนึ่งครั้ง แทนที่จะทำซ้ำในการทดสอบทั้งหมดการมีการทดสอบเพียงครั้งเดียว (และแบบเดียว) สำหรับเงื่อนไขเบื้องต้นแต่ละข้อจะช่วยให้รหัสทดสอบของคุณเป็นไปได้มากขึ้นเนื่องจากคุณจะมีการทำซ้ำน้อยลง

นอกจากนี้ยังอาจจะระบุเป็นเตรียมการสมมติ -Act-ยืนยัน

มีการจัดการทางเทคนิคสำหรับสิ่งนี้ใน NUnit ดังตัวอย่างที่นี่: http://nunit.org/index.php?p=theory&r=2.5.7

นี่คือตัวอย่าง

public void testEncompass() throws Exception {
    Range range = new Range(0, 5);
    assertFalse(range.includes(7));
    range.encompass(7);
    assertTrue(range.includes(7));
}

อาจเป็นไปได้ว่าฉันเขียนRange.includes()เพื่อกลับจริง ฉันไม่ได้ แต่ฉันสามารถจินตนาการได้ว่าฉันอาจมี หรือฉันอาจเขียนผิดด้วยวิธีอื่น ๆ ฉันหวังว่าและคาดหวังว่าด้วย TDD ฉันทำถูกแล้ว - ใช้includes()งานได้จริง - แต่บางทีฉันอาจจะไม่ ดังนั้นการยืนยันครั้งแรกคือการตรวจสอบความมีสุขภาพจิตเพื่อให้แน่ใจว่าการยืนยันครั้งที่สองมีความหมายจริงๆ

อ่านเองassertTrue(range.includes(7));บอกว่า: "ยืนยันว่าช่วงที่แก้ไขมี 7" อ่านในบริบทของการยืนยันครั้งแรกมันบอกว่า: "ยืนยันว่าการเรียก encompass ()ทำให้รวมเป็น 7 และเนื่องจาก encompass เป็นหน่วยที่เรากำลังทดสอบฉันจึงคิดว่านั่นเป็นค่า (เล็กน้อย)

ฉันยอมรับคำตอบของตัวเอง คนอื่น ๆ หลายคนเข้าใจผิดว่าคำถามของฉันเกี่ยวกับการทดสอบการตั้งค่า ฉันคิดว่านี่แตกต่างกันเล็กน้อย

การArrange-Assert-Act-Assertทดสอบสามารถ refactored เป็นสองการทดสอบ:

1. Arrange-Assert

และ

2. Arrange-Act-Assert

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

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

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

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

ตอนนี้ฉันกำลังทำสิ่งนี้ AAAA ที่แตกต่างกัน

Arrange - setup
Act - what is being tested
Assemble - what is optionally needed to perform the assert
Assert - the actual assertions

ตัวอย่างการทดสอบการอัปเดต:

Arrange: 
    New object as NewObject
    Set properties of NewObject
    Save the NewObject
    Read the object as ReadObject

Act: 
    Change the ReadObject
    Save the ReadObject

Assemble: 
    Read the object as ReadUpdated

Assert: 
    Compare ReadUpdated with ReadObject properties

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

ASSERT ควรมีเฉพาะการยืนยันเท่านั้น นั่นออกจาก ASSEMBLE ระหว่าง ACT และ ASSERT ซึ่งตั้งค่าการยืนยัน

สุดท้ายนี้หากคุณล้มเหลวในการจัดเรียงการทดสอบของคุณจะไม่ถูกต้องเนื่องจากคุณควรมีการทดสอบอื่น ๆ เพื่อป้องกัน / ค้นหาข้อบกพร่องเล็กน้อยเหล่านี้ เนื่องจากสำหรับสถานการณ์ที่ฉันนำเสนอควรมีการทดสอบอื่น ๆ อยู่แล้วซึ่งทดสอบอ่านและสร้าง หากคุณสร้าง "Guard Assertion" คุณอาจทำลาย DRY และทำการบำรุงรักษา

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

ฉันได้อ่านเกี่ยวกับเทคนิคนี้แล้ว - อาจจะมาจากคุณ btw - แต่ฉันไม่ได้ใช้มัน ส่วนใหญ่เป็นเพราะฉันคุ้นเคยกับแบบฟอร์ม Triple A สำหรับการทดสอบหน่วยของฉัน

ตอนนี้ฉันเริ่มสงสัยและมีคำถาม: คุณเขียนแบบทดสอบของคุณได้อย่างไรคุณทำให้การยืนยันนี้ล้มเหลวตามวงจรสีแดงเขียว - แดง - เขียว - refactor หรือคุณเพิ่มเข้าไปในภายหลัง

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

ฉันเคยทำสิ่งนี้มาก่อนเมื่อตรวจสอบการทดสอบที่ล้มเหลว

หลังจากเกาศีรษะหลายครั้งฉันพบว่าสาเหตุคือวิธีการที่เรียกในระหว่าง "จัดเรียง" ทำงานไม่ถูกต้อง ความล้มเหลวในการทดสอบทำให้เข้าใจผิด ฉันเพิ่ม Assert หลังการจัดเรียง สิ่งนี้ทำให้การทดสอบล้มเหลวในสถานที่ซึ่งเน้นปัญหาที่แท้จริง

ฉันคิดว่ายังมีกลิ่นรหัสที่นี่หากส่วนการจัดเรียงของการทดสอบยาวและซับซ้อนเกินไป

โดยทั่วไปแล้วฉันชอบ "จัดเรียง, กระทำ, ยืนยัน" มากและใช้เป็นมาตรฐานส่วนตัวของฉัน อย่างไรก็ตามสิ่งหนึ่งที่ไม่สามารถเตือนให้ฉันทำคือการไม่จัดเรียงสิ่งที่ฉันจัดเตรียมไว้เมื่อการยืนยันเสร็จสิ้น ในกรณีส่วนใหญ่สิ่งนี้ไม่ก่อให้เกิดความรำคาญมากนักเนื่องจากสิ่งต่างๆส่วนใหญ่หายไปอย่างน่าอัศจรรย์โดยอัตโนมัติผ่านการรวบรวมขยะเป็นต้นอย่างไรก็ตามหากคุณสร้างการเชื่อมต่อกับทรัพยากรภายนอกคุณอาจต้องการปิดการเชื่อมต่อเหล่านั้นเมื่อคุณทำเสร็จแล้ว ด้วยคำยืนยันของคุณหรือคุณหลายคนมีเซิร์ฟเวอร์หรือทรัพยากรราคาแพงอยู่ที่ไหนสักแห่งที่มีการเชื่อมต่อหรือทรัพยากรที่สำคัญซึ่งควรจะมอบให้กับคนอื่นได้ สิ่งนี้สำคัญอย่างยิ่งหากคุณเป็นหนึ่งในผู้พัฒนาที่ไม่ได้ใช้ TearDown หรือ TestFixtureTearDownเพื่อทำความสะอาดหลังจากการทดสอบอย่างน้อยหนึ่งครั้ง แน่นอนว่า "จัดเตรียมกระทำยืนยัน" จะไม่รับผิดชอบต่อความล้มเหลวในการปิดสิ่งที่ฉันเปิด ฉันพูดถึง "gotcha" นี้เท่านั้นเพราะฉันยังไม่พบคำพ้องความหมาย "A-word" ที่ดีสำหรับ "dispose" ที่จะแนะนำ! ข้อเสนอแนะใด ๆ ?

มีลักษณะที่รายการวิกิพีเดียในการออกแบบโดยสัญญา Arrange-Act-Assert Holy Trinity เป็นความพยายามที่จะเข้ารหัสแนวคิดเดียวกันบางส่วนและเป็นการพิสูจน์ความถูกต้องของโปรแกรม จากบทความ:

The notion of a contract extends down to the method/procedure level; the
contract for each method will normally contain the following pieces of
information:

    Acceptable and unacceptable input values or types, and their meanings
    Return values or types, and their meanings
    Error and exception condition values or types that can occur, and their meanings
    Side effects
    Preconditions
    Postconditions
    Invariants
    (more rarely) Performance guarantees, e.g. for time or space used

มีการแลกเปลี่ยนระหว่างความพยายามที่ใช้ในการตั้งค่านี้กับมูลค่าที่เพิ่มขึ้น AAA เป็นคำเตือนที่มีประโยชน์สำหรับขั้นตอนขั้นต่ำที่จำเป็น แต่ไม่ควรกีดกันใครจากการสร้างขั้นตอนเพิ่มเติม

ขึ้นอยู่กับสภาพแวดล้อม / ภาษาการทดสอบของคุณ แต่โดยปกติแล้วหากบางสิ่งในส่วนการจัดเรียงล้มเหลวข้อยกเว้นจะถูกโยนทิ้งและการทดสอบล้มเหลวในการแสดงผลแทนที่จะเริ่มส่วนพระราชบัญญัติ ดังนั้นไม่ฉันมักจะไม่ใช้ Assert ส่วนที่สอง

นอกจากนี้ในกรณีที่ส่วนการจัดเรียงของคุณค่อนข้างซับซ้อนและไม่ได้มีข้อยกเว้นเสมอไปคุณอาจพิจารณาห่อด้วยวิธีการบางอย่างและเขียนแบบทดสอบของตัวเองเพื่อให้คุณมั่นใจได้ว่าจะไม่ล้มเหลว (หากไม่มี โยนข้อยกเว้น)

ฉันไม่ใช้รูปแบบนั้นเพราะฉันคิดว่าจะทำสิ่งที่ชอบ:

Arrange
Assert-Not
Act
Assert

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

โดยใช้ตัวอย่างคำตอบของคุณ:

public void testEncompass() throws Exception {
    Range range = new Range(0, 5);
    assertFalse(range.includes(7)); // <-- Pointless and against DRY if there 
                                    // are unit tests for Range(int, int)
    range.encompass(7);
    assertTrue(range.includes(7));
}

หากคุณต้องการทดสอบทุกอย่างในตัวอย่างให้ลองทดสอบเพิ่มเติม ... เช่น:

public void testIncludes7() throws Exception {
    Range range = new Range(0, 5);
    assertFalse(range.includes(7));
}

public void testIncludes5() throws Exception {
    Range range = new Range(0, 5);
    assertTrue(range.includes(5));
}

public void testIncludes0() throws Exception {
    Range range = new Range(0, 5);
    assertTrue(range.includes(0));
}

public void testEncompassInc7() throws Exception {
    Range range = new Range(0, 5);
    range.encompass(7);
    assertTrue(range.includes(7));
}

public void testEncompassInc5() throws Exception {
    Range range = new Range(0, 5);
    range.encompass(7);
    assertTrue(range.includes(5));
}

public void testEncompassInc0() throws Exception {
    Range range = new Range(0, 5);
    range.encompass(7);
    assertTrue(range.includes(0));
}

เพราะไม่เช่นนั้นคุณจะพลาดโอกาสผิดพลาดมากมาย ... เช่นหลังจากล้อมรอบแล้วช่วงจะมีเพียง 7 เท่านั้นเป็นต้นนอกจากนี้ยังมีการทดสอบความยาวของช่วง (เพื่อให้แน่ใจว่ามันไม่ได้รวมค่าสุ่มด้วย) และ ชุดการทดสอบอื่นทั้งหมดสำหรับการพยายามรวม 5 ในช่วง ... สิ่งที่เราคาดหวัง - ข้อยกเว้นในการล้อมรอบหรือช่วงที่จะไม่มีการเปลี่ยนแปลง?

อย่างไรก็ตามประเด็นก็คือหากมีสมมติฐานใด ๆ ในการกระทำที่คุณต้องการทดสอบให้ทดสอบด้วยตัวเองใช่หรือไม่?

ฉันใช้:

1. Setup
2. Act
3. Assert 
4. Teardown

เนื่องจากการตั้งค่าใหม่ทั้งหมดมีความสำคัญมาก