หนึ่งควรทดสอบค่าของ enum โดยใช้การทดสอบหน่วย?

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

ฉันคิดว่าพวกเขาควรจะเขียนแม้ว่าพวกเขาจะดูเรียบง่ายและซ้ำซ้อนฉันพิจารณาว่าสิ่งที่เกี่ยวข้องกับข้อกำหนดทางธุรกิจควรจะเขียนอย่างชัดเจนในการทดสอบไม่ว่าจะเป็นกับหน่วย / บูรณาการ / UI / ฯลฯ การทดสอบหรือโดยใช้ระบบประเภทของภาษาเป็นวิธีการทดสอบ เนื่องจากค่าที่ enum (เช่นใน Java) ต้องมีจากมุมมองของธุรกิจจึงไม่สามารถทดสอบได้โดยใช้ระบบชนิดที่ฉันคิดว่าควรมีการทดสอบหน่วยสำหรับสิ่งนั้น

คำถามนี้ไม่คล้ายกับคำถามนี้เพราะมันไม่ได้แก้ปัญหาเดียวกับของฉัน ในคำถามนั้นมีฟังก์ชั่นธุรกิจ (savePeople) และบุคคลกำลังสอบถามเกี่ยวกับการใช้งานภายใน (forEach) ในนั้นมีชั้นธุรกิจกลาง (ฟังก์ชั่นบันทึกคน) encapsulating การสร้างภาษา (forEach) นี่สร้างภาษา (enum) เป็นสิ่งที่ใช้ในการระบุพฤติกรรมจากมุมมองทางธุรกิจ

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

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

ไม่พวกเขาเป็นเพียงรัฐ

พื้นฐานความจริงที่ว่าคุณกำลังใช้ enum เป็นรายละเอียดการดำเนินงาน ; นั่นเป็นสิ่งที่คุณอาจต้องการปรับโครงสร้างในการออกแบบที่แตกต่างกัน

การทดสอบ enums เพื่อความสมบูรณ์นั้นคล้ายคลึงกับการทดสอบว่าจำนวนเต็มที่แทนได้ทั้งหมดนั้นมีอยู่

การทดสอบพฤติกรรมที่การแจกแจงสนับสนุนเป็นความคิดที่ดี กล่าวอีกนัยหนึ่งถ้าคุณเริ่มจากชุดการทดสอบที่ผ่านมาและใส่ความคิดเห็นออกค่า enum ใด ๆ การทดสอบอย่างน้อยหนึ่งครั้งควรล้มเหลว

คุณไม่ได้ทดสอบ Enum ที่ประกาศ คุณอาจทดสอบว่าฟังก์ชันอินพุต / เอาต์พุตมีค่า enum ที่คาดหวังหรือไม่ ตัวอย่าง:

enum Parity {
    Even,
    Odd
}

Parity GetParity(int x) { ... }

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

คุณไม่ทดสอบการเขียนการตรวจสอบGetParityพูดจะกลับEven0, Odd1 และอื่น ๆ สิ่งนี้มีค่าเพราะคุณไม่ได้ทำซ้ำรหัสคุณกำลังตรวจสอบพฤติกรรมของรหัสโดยไม่ขึ้นอยู่กับการใช้งาน หากรหัสด้านในGetParityถูกเขียนใหม่ทั้งหมดการทดสอบจะยังคงใช้ได้ ประโยชน์ที่สำคัญของการทดสอบหน่วยคือพวกเขาให้อิสระในการเขียนและสร้างรหัสใหม่อย่างปลอดภัยโดยรับรองว่ารหัสยังคงทำงานตามที่คาดไว้

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

หากมีความเสี่ยงที่การเปลี่ยน enum จะทำให้รหัสของคุณแตกหักแน่นอนว่าทุกอย่างที่มีแอตทริบิวต์ [Flags] ใน C # น่าจะเป็นกรณีที่ดีเพราะการเพิ่มค่าระหว่าง 2 และ 4 (3) จะเป็นบิต 1 และ 2 มากกว่า รายการที่รอบคอบ

มันเป็นชั้นของการป้องกัน

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

ฉันเคยเห็นคน "แก้ไข" การใช้อักษรตัวใหญ่ของรายการ enum แล้วเรียงลำดับตามตัวอักษรหรือโดยกลุ่มตรรกะอื่น ๆ

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

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

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

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

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

ฉันเคยมีกรณีที่โมดูลหนึ่งใช้ enums ประเภทจากโมดูลอื่นสองและแมประหว่างพวกเขา (หนึ่งใน enums มีตรรกะเพิ่มเติมด้วยอีกอันหนึ่งเป็นการเข้าถึงฐานข้อมูลทั้งคู่มีการพึ่งพาซึ่งควรแยกออกจากกัน)

ในกรณีนี้ฉันเพิ่มการทดสอบ (ในโมดูลการทำแผนที่) ซึ่งตรวจสอบว่ารายการ enum ทั้งหมดใน enum ต้นทางนั้นมีอยู่ใน enum เป้าหมาย (และดังนั้นการทำแผนที่จะทำงานได้เสมอ) (สำหรับบางกรณีฉันยังตรวจสอบวิธีอื่น ๆ ด้วย)

วิธีนี้เมื่อมีคนเพิ่มรายการ enum ให้กับ enums หนึ่งและลืมที่จะเพิ่มรายการที่สอดคล้องกับอีกรายการหนึ่งการทดสอบเริ่มล้มเหลว

Enums เป็นประเภทที่ จำกัด เพียงแค่ชื่อที่กำหนดเอง Enum อาจมีเพียงหนึ่งค่าเช่นเดียวกับvoidที่มีอยู่เท่านั้นnull(บางภาษาเรียกสิ่งนี้unitและใช้ชื่อvoidสำหรับ enum ที่ไม่มีองค์ประกอบ!) มันอาจจะมีสองค่าเช่นboolที่มีและfalse trueมันอาจจะมีสามเช่นcolourChannelมีred, และgreen blueและอื่น ๆ

หากสอง enums มีค่าเท่ากันแสดงว่าเป็น "isomorphic"; เช่นถ้าเราเปลี่ยนชื่อทั้งหมดอย่างเป็นระบบจากนั้นเราสามารถใช้ชื่ออื่นแทนและโปรแกรมของเราจะไม่ทำงานแตกต่างกัน โดยเฉพาะอย่างยิ่งการทดสอบของเราจะไม่ทำงานแตกต่างกัน!

ตัวอย่างเช่นresultมีwin/ lose/ drawเป็น isomorphic ข้างต้นcolourChannelเนื่องจากเราสามารถแทนที่เช่นcolourChannelกับresult, redกับwin, greenด้วยloseและblueด้วยdrawและตราบใดที่เราทำได้ทุกที่ (ผลิตและผู้บริโภค parsers และ serialisers รายการฐานข้อมูลไฟล์บันทึก ฯลฯ ) จากนั้นจะไม่มีการเปลี่ยนแปลงในโปรแกรมของเรา " colourChannelการทดสอบ" ที่เราเขียนจะยังคงผ่านแม้ว่าจะไม่มีcolourChannelอีกต่อไป!

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

สิ่งที่หมายถึงนี้ก็คือว่าเท่าที่เป็นเครื่องที่เป็นห่วง enums มี "ชื่อที่แตกต่าง" และไม่มีอะไรอื่น สิ่งเดียวที่เราสามารถทำได้ด้วย enum คือการแยกสาขาว่าค่าสองค่านั้นเหมือนกัน (เช่นred/ red) หรือแตกต่างกัน (เช่นred/ blue) นั่นคือสิ่งเดียวที่ 'การทดสอบหน่วย' สามารถทำได้เช่น

(  red == red  ) || throw TestFailure;
(green == green) || throw TestFailure;
( blue == blue ) || throw TestFailure;
(  red != green) || throw TestFailure;
(  red != blue ) || throw TestFailure;
...

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

นั่นคือทฤษฎี แล้วการฝึกฝนล่ะ? ปัญหาหลักของคุณลักษณะนี้คือโปรแกรม 'โลกแห่งความจริง' ไม่ค่อยมีอยู่ในตัวเอง: เรามีรุ่นดั้งเดิม, การปรับใช้แบบรีโมต / ฝังตัว, ข้อมูลประวัติ, การสำรองข้อมูล, ฐานข้อมูลสดเป็นต้นดังนั้นเราจึงไม่สามารถ 'เปลี่ยน' ได้จริงๆ การเกิดขึ้นของชื่อทั้งหมดโดยไม่พลาดการใช้งานบางอย่าง

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

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

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

• การครอบคลุมรหัสสามารถบอกเราได้ว่าความหลากหลายของค่า enum ที่มาจากชุดทดสอบนั้นเพียงพอที่จะกระตุ้นให้สาขาต่าง ๆ ในรหัสนั้น ถ้าไม่เราสามารถเพิ่มการทดสอบที่เรียกสาขาที่ไม่ได้เปิดหรือสร้างความหลากหลายที่กว้างขึ้นของการทดสอบที่มีอยู่
• การตรวจสอบคุณสมบัติสามารถบอกเราได้ว่ามีความหลากหลายของสาขาในรหัสเพียงพอที่จะจัดการกับความเป็นไปได้ของรันไทม์หรือไม่ ตัวอย่างเช่นหากโค้ดจัดการเท่านั้นredและเราทดสอบด้วยredเท่านั้นเราจะมีความครอบคลุม 100% ตัวตรวจสอบคุณสมบัติจะ (พยายาม) สร้างตัวอย่างให้กับการยืนยันของเราเช่นการสร้างgreenและblueค่าที่เราลืมทดสอบ
• การทดสอบการกลายพันธุ์สามารถบอกเราได้ว่าการยืนยันของเราตรวจสอบ enum จริง ๆเพียงแค่ติดตามกิ่งไม้และไม่สนใจความแตกต่าง

ไม่การทดสอบหน่วยสำหรับการทดสอบหน่วย

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

https://en.wikipedia.org/wiki/Unit_testing

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

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

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

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

โปรดทราบว่าคุณไม่ต้องการชื่อที่มีความหมายสำหรับรหัสของคุณเพื่อทำสิ่งที่ถูกต้องนั่นเป็นเพียงความสะดวกสบายสำหรับผู้ที่อ่านรหัสของคุณ คุณสามารถทำให้การทำงานของรหัสของคุณมีค่า enum เหมือนfoo, bar... frobnicate()และวิธีการเช่น