เส้นแบ่งระหว่างตรรกะการทดสอบหน่วยแอปพลิเคชันกับการสร้างภาษาที่ไม่ไว้ใจอยู่ที่ไหน

พิจารณาฟังก์ชั่นเช่นนี้:

function savePeople(dataStore, people) {
    people.forEach(person => dataStore.savePerson(person));
}

มันอาจจะใช้แบบนี้:

myDataStore = new Store('some connection string', 'password');
myPeople = ['Joe', 'Maggie', 'John'];
savePeople(myDataStore, myPeople);

ให้เราสมมติว่าStoreมีการทดสอบหน่วยของตนเองหรือได้รับการจัดหาจากผู้ขาย ในกรณีใด ๆ Storeเราไว้วางใจ และให้เราต่อไปคิดว่าจัดการข้อผิดพลาด - เช่นข้อผิดพลาดการเชื่อมต่อฐานข้อมูล - savePeopleไม่ได้เป็นความรับผิดชอบของ ที่จริงให้เราสมมติว่าตัวร้านนั้นเป็นฐานข้อมูลเวทมนต์ที่ไม่สามารถผิดพลาดได้ แต่อย่างใด ด้วยสมมติฐานเหล่านี้คำถามคือ:

ควรsavePeople()ทดสอบหน่วยหรือจำนวนการทดสอบดังกล่าวเพื่อทดสอบการสร้างforEachภาษาในตัว?

แน่นอนเราสามารถผ่านการเยาะเย้ยdataStoreและยืนยันที่dataStore.savePerson()เรียกว่าครั้งเดียวสำหรับแต่ละคน แน่นอนคุณสามารถโต้แย้งว่าการทดสอบดังกล่าวมีความปลอดภัยต่อการเปลี่ยนแปลงการใช้งานเช่นหากเราตัดสินใจแทนที่forEachด้วยการforวนซ้ำดั้งเดิมหรือวิธีการทำซ้ำอื่น ๆ ดังนั้นการทดสอบไม่ได้อย่างสิ้นเชิงจิ๊บจ๊อย และยังดูเหมือนว่าใกล้มาก ...

นี่เป็นอีกตัวอย่างที่อาจมีผลมากกว่า พิจารณาฟังก์ชั่นที่ไม่ทำอะไรเลยนอกจากประสานงานวัตถุหรือฟังก์ชั่นอื่น ๆ ตัวอย่างเช่น:

function bakeCookies(dough, pan, oven) {
    panWithRawCookies = pan.add(dough);
    oven.addPan(panWithRawCookies);
    oven.bakeCookies();
    oven.removePan();
}

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

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

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

เมื่อผู้ใช้สร้างบัญชีใหม่สิ่งต่าง ๆ ต้องเกิดขึ้น: 1) ต้องมีการสร้างบันทึกผู้ใช้ใหม่ในฐานข้อมูล 2) ต้องส่งอีเมลต้อนรับ 3) ที่อยู่ IP ของผู้ใช้ต้องถูกบันทึกไว้เนื่องจากการฉ้อโกง วัตถุประสงค์

ดังนั้นเราต้องการสร้างวิธีการที่เชื่อมโยงทุกขั้นตอน "ผู้ใช้ใหม่":

function createNewUser(validatedUserData, emailService, dataStore) {
  userId = dataStore.insertUserRecord(validateduserData);
  emailService.sendWelcomeEmail(validatedUserData);
  dataStore.recordIpAddress(userId, validatedUserData.ip);
}

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

สาระสำคัญของความสับสนของฉันคือการทดสอบหน่วยฟังก์ชั่นดังกล่าวดูเหมือนว่าจำเป็นต้องทำซ้ำการใช้งานที่แน่นอนในการทดสอบตัวเอง (โดยระบุว่าวิธีการที่เรียกว่าบน mocks ในลำดับที่แน่นอน) และดูเหมือนว่าผิด

ควรsavePeople()จะทดสอบหน่วย? ใช่. คุณไม่ได้ทำการทดสอบที่ใช้dataStore.savePersonงานได้หรือการเชื่อมต่อฐานข้อมูลนั้นใช้foreachงานได้ คุณกำลังทดสอบที่savePeopleทำตามสัญญาที่ทำผ่านสัญญา

ลองนึกภาพสถานการณ์นี้: ใครบางคนทำ refactor ขนาดใหญ่ของฐานรหัสและลบforEachส่วนหนึ่งของการนำไปใช้โดยไม่ได้ตั้งใจเพื่อให้มันบันทึกเฉพาะรายการแรกเท่านั้น คุณไม่ต้องการทดสอบหน่วยที่จะจับที่?

โดยทั่วไปแล้วคำถามประเภทนี้จะเกิดขึ้นเมื่อผู้คนทำการพัฒนา "หลังการทดสอบ" เข้าหาปัญหานี้จากมุมมองของ TDD ที่การทดสอบมาก่อนการใช้งานและถามคำถามนี้กับตัวเองอีกครั้งในแบบฝึกหัด

อย่างน้อยในแอปพลิเคชัน TDD ของฉันซึ่งโดยปกติแล้วจะอยู่ภายนอกฉันจะไม่ใช้งานฟังก์ชั่นเหมือนsavePeopleหลังจากใช้งานsavePersonไปแล้ว savePeopleและsavePersonฟังก์ชั่นจะเริ่มต้นเป็นหนึ่งและถูกทดสอบขับเคลื่อนจากการทดสอบหน่วยเดียวกัน การแยกระหว่างทั้งสองจะเกิดขึ้นหลังจากการทดสอบสองสามครั้งในขั้นตอนการสร้างใหม่ โหมดของการทำงานนอกจากนี้ยังจะก่อให้เกิดคำถามที่ฟังก์ชั่นที่savePeopleควรจะเป็น - dataStoreไม่ว่าจะเป็นฟังก์ชั่นฟรีหรือเป็นส่วนหนึ่งของ

ในท้ายที่สุดการทดสอบไม่เพียง แต่จะตรวจสอบว่าคุณสามารถบันทึกได้อย่างถูกต้องPersonในStoreแต่ยังมีหลายคน สิ่งนี้จะทำให้ฉันถามว่าการตรวจสอบอื่น ๆ มีความจำเป็นหรือไม่ตัวอย่างเช่น "ฉันต้องตรวจสอบให้แน่ใจว่าsavePeopleฟังก์ชั่นนั้นเป็นแบบอะตอมมิกไม่ว่าจะบันทึกทั้งหมดหรือไม่?", "มันจะคืนข้อผิดพลาด จะไม่ถูกบันทึกอย่างไรข้อผิดพลาดเหล่านั้นจะมีลักษณะอย่างไร "และอื่น ๆ จำนวนทั้งหมดนี้มากกว่าการตรวจสอบการใช้forEachซ้ำหรือรูปแบบอื่น ๆ

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

ควร savePeople () ทดสอบเป็นหน่วย

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

function testSavePeople() {
    myDataStore = new Store('some connection string', 'password');
    myPeople = ['Joe', 'Maggie', 'John'];
    savePeople(myDataStore, myPeople);
    assert(myDataStore.containsPerson('Joe'));
    assert(myDataStore.containsPerson('Maggie'));
    assert(myDataStore.containsPerson('John'));
}

การทดสอบนี้ทำหลายสิ่ง:

• มันตรวจสอบสัญญาของฟังก์ชั่น savePeople()
• มันไม่สนใจเกี่ยวกับการดำเนินการของ savePeople()
• มันบันทึกตัวอย่างการใช้งานของ savePeople()

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

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

หรือจำนวนการทดสอบดังกล่าวเพื่อทดสอบโครงสร้างภาษาสำหรับแต่ละภาษาหรือไม่

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

เกี่ยวกับการอัปเดตคำถามของคุณ:

ทดสอบการเปลี่ยนแปลงสถานะ! เช่นจะใช้แป้งบางส่วน ตามการใช้งานของคุณยืนยันว่าจำนวนการใช้งานที่doughพอดีpanหรือยืนยันว่าการdoughใช้หมดแล้ว ยืนยันว่าpanมีคุกกี้หลังจากการเรียกใช้ฟังก์ชัน ยืนยันว่าovenว่าง / อยู่ในสถานะเดียวกับเมื่อก่อน

สำหรับการทดสอบเพิ่มเติมตรวจสอบกรณีขอบ: จะเกิดอะไรขึ้นถ้าovenไม่ว่างเปล่าก่อนที่จะโทร? เกิดอะไรขึ้นถ้ามีอยู่ไม่เพียงพอdough? ถ้าpanเต็มแล้ว?

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

ในความเป็นจริงผู้ใช้ TDD ส่วนใหญ่เขียนการทดสอบก่อนที่พวกเขาจะเขียนฟังก์ชันดังนั้นพวกเขาจึงไม่ได้ขึ้นอยู่กับการใช้งานจริง

สำหรับการเพิ่มล่าสุดของคุณ:

เมื่อผู้ใช้สร้างบัญชีใหม่สิ่งต่าง ๆ ต้องเกิดขึ้น: 1) ต้องมีการสร้างบันทึกผู้ใช้ใหม่ในฐานข้อมูล 2) ต้องส่งอีเมลต้อนรับ 3) ที่อยู่ IP ของผู้ใช้ต้องถูกบันทึกไว้เนื่องจากการฉ้อโกง วัตถุประสงค์

ดังนั้นเราต้องการสร้างวิธีการที่เชื่อมโยงทุกขั้นตอน "ผู้ใช้ใหม่":

function createNewUser(validatedUserData, emailService, dataStore) {
    userId = dataStore.insertUserRecord(validateduserData);
    emailService.sendWelcomeEmail(validatedUserData);
    dataStore.recordIpAddress(userId, validatedUserData.ip);
}

สำหรับฟังก์ชั่นเช่นนี้ฉันจะเยาะเย้ย / ต้นขั้ว / ปลอม (สิ่งที่ดูเหมือนทั่วไปมากขึ้น) dataStoreและemailServiceพารามิเตอร์ ฟังก์ชั่นนี้ไม่ได้ทำการเปลี่ยนสถานะใด ๆ กับพารามิเตอร์ใด ๆ ด้วยตัวเองมันจะมอบหมายให้กับวิธีการบางอย่างของพวกเขา ฉันจะพยายามตรวจสอบว่าการเรียกใช้ฟังก์ชันทำ 4 สิ่ง:

• มันแทรกผู้ใช้ลงในแหล่งข้อมูล
• มันส่ง (หรืออย่างน้อยเรียกว่าวิธีการที่เกี่ยวข้อง) อีเมลต้อนรับ
• มันบันทึก IP ของผู้ใช้ลงในแหล่งข้อมูล
• มันมอบหมายข้อยกเว้น / ข้อผิดพลาดที่พบ (ถ้ามี)

การตรวจสอบ 3 ครั้งแรกสามารถทำได้ด้วย mocks, stubs หรือ fakes of dataStoreและemailService(คุณไม่ต้องการส่งอีเมลเมื่อทำการทดสอบ) เนื่องจากฉันต้องค้นหาความคิดเห็นบางส่วนสิ่งเหล่านี้จึงแตกต่าง:

• ของปลอมเป็นวัตถุที่มีพฤติกรรมเหมือนกับต้นฉบับและอยู่ในขอบเขตที่แยกไม่ออก รหัสของมันสามารถนำกลับมาใช้ซ้ำได้ตลอดการทดสอบ เช่นนี้สามารถเป็นฐานข้อมูลในหน่วยความจำง่ายสำหรับ wrapper ฐานข้อมูล
• ต้นขั้วเพียงดำเนินการเท่าที่จำเป็นเพื่อตอบสนองการดำเนินงานที่จำเป็นของการทดสอบนี้ ในกรณีส่วนใหญ่ต้นขั้วนั้นมีความเฉพาะเจาะจงกับการทดสอบหรือกลุ่มการทดสอบที่ต้องการวิธีการดั้งเดิมเพียงเล็กน้อย ในตัวอย่างนี้มันอาจจะเป็นdataStoreที่เพิ่งดำเนินการรุ่นที่เหมาะสมและinsertUserRecord()recordIpAddress()
• การเยาะเย้ยเป็นวัตถุที่ช่วยให้คุณตรวจสอบวิธีการใช้งาน (ส่วนใหญ่มักให้คุณประเมินการโทรไปยังวิธีการ) ฉันพยายามใช้พวกเขาเท่าที่จำเป็นในการทดสอบหน่วยเนื่องจากใช้พวกคุณจริง ๆ แล้วลองทดสอบการใช้งานฟังก์ชั่นไม่ใช่การยึดติดกับส่วนต่อประสาน แต่มันก็ยังคงมีการใช้งานอยู่ เฟรมเวิร์กจำลองจำนวนมากมีอยู่เพื่อช่วยคุณสร้างเฉพาะจำลองที่คุณต้องการ

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

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

สาระสำคัญของความสับสนของฉันคือการทดสอบหน่วยฟังก์ชั่นดังกล่าวดูเหมือนว่าจำเป็นต้องทำซ้ำการใช้งานที่แน่นอนในการทดสอบตัวเอง (โดยระบุว่าวิธีการที่เรียกว่าบน mocks ในลำดับที่แน่นอน) และดูเหมือนว่าผิด

บางครั้งสิ่งนี้จะต้องทำ (แม้ว่าคุณส่วนใหญ่สนใจในเรื่องนี้ในการทดสอบการรวม) บ่อยครั้งมีวิธีอื่น ๆ ในการตรวจสอบผลข้างเคียง / การเปลี่ยนแปลงสถานะที่คาดหวัง

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

น่าเศร้าที่ในกรณีนั้นการทดสอบหน่วยสูญเสียความน่าเชื่อถือบางส่วน: เนื่องจากมีการเปลี่ยนแปลงจึงไม่ยืนยันฟังก์ชันหลังจากการเปลี่ยนแปลงนั้นทำแบบเดียวกับที่เคยเป็นมา

ยกตัวอย่างเช่นลองพิจารณาว่ามีคนเพิ่มการเรียกไปที่oven.preheat()(การเพิ่มประสิทธิภาพ!) ในตัวอย่างการอบคุกกี้ของคุณ:

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

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

ค่าหลักเช่นการทดสอบให้คือมันทำให้การใช้งานของคุณ refactorable

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

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

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

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

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

ฉันจะเพิ่มความคิดที่ฉันได้รับจากผู้สอน TDD อย่าทดสอบวิธีการ ทดสอบพฤติกรรม คุณไม่ได้ทดสอบว่าใช้savePeopleงานได้จริงคุณกำลังทดสอบว่าผู้ใช้หลายคนสามารถบันทึกได้ในการโทรครั้งเดียว

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

ควรbakeCookies()จะทดสอบ ใช่.

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

ไม่ได้จริงๆ ดูอย่างใกล้ชิดว่าฟังก์ชันควรทำอะไร - ควรตั้งค่าovenวัตถุให้อยู่ในสถานะที่ระบุ เมื่อมองไปที่รหัสปรากฏว่าสถานะของpanและdoughวัตถุไม่สำคัญมากนัก ดังนั้นคุณควรผ่านovenวัตถุ (หรือจำลอง) และยืนยันว่ามันอยู่ในสถานะเฉพาะเมื่อสิ้นสุดการเรียกใช้ฟังก์ชัน

ในคำอื่น ๆที่คุณควรยืนยันว่าbakeCookies()อบคุกกี้

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

การทดสอบหน่วยทำหน้าที่สองฟังก์ชั่น:

1. มันทดสอบว่าทุกอย่างทำงานได้ นี่คือการทดสอบหน่วยฟังก์ชันที่มีประโยชน์น้อยที่สุดและดูเหมือนว่าคุณจะพิจารณาฟังก์ชั่นนี้เฉพาะเมื่อถามคำถามเท่านั้น

2. จะตรวจสอบเพื่อดูว่าการปรับเปลี่ยนในอนาคตของโปรแกรมไม่ทำลายฟังก์ชันการทำงานที่นำไปใช้ก่อนหน้านี้ นี่เป็นฟังก์ชั่นที่มีประโยชน์ที่สุดของการทดสอบหน่วยและป้องกันการแนะนำบั๊กในโปรแกรมขนาดใหญ่ มันมีประโยชน์ในการเขียนโปรแกรมปกติเมื่อเพิ่มคุณสมบัติให้กับโปรแกรม แต่มีประโยชน์มากกว่าในการปรับโครงสร้างและการปรับให้เหมาะสมซึ่งอัลกอริธึมหลักในการนำโปรแกรมไปใช้นั้นมีการเปลี่ยนแปลงอย่างมากโดยไม่เปลี่ยนแปลงพฤติกรรมที่สังเกตได้ของโปรแกรม

อย่าทดสอบโค้ดภายในฟังก์ชั่น แทนที่จะทดสอบว่าฟังก์ชั่นทำในสิ่งที่มันบอกว่าทำ เมื่อคุณดูการทดสอบหน่วยด้วยวิธีนี้ (ทดสอบฟังก์ชั่นไม่ใช่รหัส) คุณจะรู้ว่าคุณไม่เคยทดสอบการสร้างภาษาหรือแม้แต่ตรรกะการใช้งาน คุณกำลังทดสอบ API

ควร savePeople () ทำการทดสอบหน่วยหรือจำนวนการทดสอบดังกล่าวเพื่อทดสอบโครงสร้างภาษา forEach หรือไม่

ใช่. แต่คุณสามารถทำได้ในวิธีที่จะทดสอบการก่อสร้างอีกครั้ง

สิ่งที่ควรทราบที่นี่คือฟังก์ชั่นนี้ทำงานอย่างไรเมื่อsavePersonล้มเหลวไปครึ่งทาง? มันควรจะทำงานอย่างไร

นั่นคือการเรียงลำดับของพฤติกรรมที่ละเอียดอ่อนที่ฟังก์ชั่นให้คุณควรบังคับใช้กับการทดสอบหน่วย

กุญแจสำคัญในที่นี้คือมุมมองของคุณเกี่ยวกับฟังก์ชั่นบางอย่างที่ไม่สำคัญ การเขียนโปรแกรมส่วนใหญ่เป็นเรื่องไม่สำคัญ: กำหนดค่าทำคณิตศาสตร์ทำในการตัดสินใจ: ถ้าเป็นเช่นนั้นให้ทำต่อไปเรื่อย ๆ จนกว่าจะถึง ... คุณเพิ่งผ่าน 5 บทแรกของหนังสือใด ๆ ที่สอนภาษาการเขียนโปรแกรม

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

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

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

ควร savePeople () ทำการทดสอบหน่วยหรือจำนวนการทดสอบดังกล่าวเพื่อทดสอบโครงสร้างภาษา forEach หรือไม่

@BryanOakley ได้รับคำตอบนี้แล้ว แต่ฉันมีข้อโต้แย้งเพิ่มเติม (ฉันเดา):

ขั้นแรกการทดสอบหน่วยสำหรับการทดสอบการปฏิบัติตามสัญญาไม่ใช่การบังคับใช้ API การทดสอบควรตั้งเงื่อนไขเบื้องต้นจากนั้นเรียกจากนั้นตรวจสอบผลกระทบผลข้างเคียงค่าคงที่ใด ๆ และเงื่อนไขการโพสต์ เมื่อคุณตัดสินใจว่าจะทดสอบการดำเนินงานของ API ไม่ได้ (และไม่ควร) เรื่อง

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

ประการที่สามมีคุณค่าในการใช้การทดสอบเล็กน้อยทั้งในวิธีการ TDD (ซึ่งสั่งมัน) และนอกมัน

เมื่อเขียน C ++ สำหรับชั้นเรียนของฉันฉันมักจะเขียนแบบทดสอบเล็กน้อยที่ยกตัวอย่างวัตถุและตรวจสอบค่าคงที่ (กำหนดได้ปกติและอื่น ๆ ) ฉันพบว่ามันน่าประหลาดใจที่การทดสอบนี้ขาดระหว่างการพัฒนา (เช่น - โดยการเพิ่มสมาชิกที่ไม่สามารถเคลื่อนที่ได้ในชั้นเรียนโดยไม่ได้ตั้งใจ)

ฉันคิดว่าคำถามของคุณเดือดลงไปที่:

ฉันจะทดสอบฟังก์ชั่นโมฆะโดยไม่ต้องทดสอบการรวมได้อย่างไร

หากเราเปลี่ยนฟังก์ชั่นการอบคุกกี้ของคุณเพื่อส่งคืนคุกกี้ตัวอย่างเช่นจะเห็นได้ชัดทันทีว่าการทดสอบควรเป็นอย่างไร

ถ้าเราต้องเรียกใช้ pan.GetCookies หลังจากเรียกฟังก์ชั่นแม้ว่าเราจะสามารถตั้งคำถามว่า 'การทดสอบการรวมระบบ' หรือ 'แต่เราไม่ได้ทดสอบวัตถุแพนหรือไม่'

ฉันคิดว่าคุณถูกต้องในการที่มีการทดสอบหน่วยกับทุกสิ่งที่ล้อเลียนและเพียงตรวจสอบฟังก์ชั่น xy และ z ถูกเรียกว่าขาดค่า

แต่! ฉันจะโต้แย้งว่าในกรณีนี้คุณควร refactor ฟังก์ชั่นโมฆะของคุณเพื่อส่งกลับผลการทดสอบหรือใช้วัตถุจริงและทำการทดสอบแบบบูรณาการ

--- อัพเดตสำหรับตัวอย่าง createNewUser

• จำเป็นต้องสร้างเรคคอร์ดผู้ใช้ใหม่ในฐานข้อมูล
• จะต้องส่งอีเมลต้อนรับ
• ต้องบันทึกที่อยู่ IP ของผู้ใช้เพื่อวัตถุประสงค์ในการฉ้อโกง

ตกลงดังนั้นในเวลานี้ผลลัพธ์ของฟังก์ชันจะไม่ถูกส่งคืนได้อย่างง่ายดาย เราต้องการเปลี่ยนสถานะของพารามิเตอร์

นี่คือที่ฉันได้รับการโต้เถียงเล็กน้อย ฉันสร้างการใช้งานจำลองที่เป็นรูปธรรมสำหรับพารามิเตอร์ stateful

ได้โปรดผู้อ่านที่รักลองและควบคุมความโกรธของคุณ!

ดังนั้น...

var validatedUserData = new UserData(); //we can use the real object for this
var emailService = new MockEmailService(); //a simple mock which saves sentEmails to a List<string>
var dataStore = new MockDataStore(); //a simple mock which saves ips to a List<string>

//run the test
target.createNewUser(validatedUserData, emailService, dataStore);

//check the results
Assert.AreEqual(1, emailService.EmailsSent.Count());
Assert.AreEqual(1, dataStore.IpsRecorded.Count());
Assert.AreEqual(1, dataStore.UsersSaved.Count());

วิธีนี้จะแยกรายละเอียดการใช้งานของวิธีการทดสอบออกจากพฤติกรรมที่ต้องการ การใช้งานทางเลือก:

function createNewUser(validatedUserData, emailService, dataStore) {
  userId = dataStore.bulkInsedrtUserRecords(new [] {validateduserData});
  emailService.addEmailToQueue(validatedUserData);
  emailService.ProcessQueue();
  dataStore.recordIpAddress(userId, validatedUserData.ip);
}

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

คุณควรทดสอบด้วยเช่นกันbakeCookies- จะbakeCookies(egg, pan, oven)ให้ผลตอบแทนอะไรบ้าง? ไข่ดาวหรือข้อยกเว้น? ของตัวเองค่าpanมิได้ovenจะดูแลเกี่ยวกับส่วนผสมที่เกิดขึ้นจริงเนื่องจากไม่มีของพวกเขาควรจะ แต่bakeCookiesมักจะควรผลผลิตคุกกี้ โดยทั่วไปก็สามารถขึ้นอยู่กับวิธีการที่doughจะได้รับและไม่ว่าจะมีเป็นโอกาสใด ๆ ของมันกลายเป็นเพียงeggหรือเช่นwaterแทน