ฉันจำเป็นต้องทดสอบทุกอย่างหรือไม่

28

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

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

testing tdd

— Matteo Pagliazzi
แหล่งที่มา

9

นี่ไม่ใช่คำถามเกี่ยวกับรางรถไฟ มันเป็นคำถามของ TDD

— Jon Strayer

4

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

— pdr

1

ด้วยเหตุผลบางอย่างคำถามนี้ทำให้ฉันต้องการโพสต์ภาพมาโครของ Captain Nero ตะโกน "TEST EVERYTHING !!!"

— Mason Wheeler

3

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

— ZJR

1

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

— Evan Plaice

47

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

ดังนั้นเมื่อทราบแล้วพฤติกรรมของหน้าสแตติกคืออะไรและอินเทอร์เฟซคืออะไร

คำตอบแรกของฉันคือ "none" และ "none"

— จอน Strayer
แหล่งที่มา

ดังนั้นไม่มีการทดสอบหน้าคงที่?

— Matteo Pagliazzi

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

— Robert Harvey

@MatteoPagliazzi ขึ้นอยู่กับระดับของการทดสอบ (การทดสอบหน่วย / การรวมการทดสอบ / ฯลฯ ) อาจจะหนึ่งหรือสองเพื่อยืนยันหน้าคงที่สามารถเข้าถึงได้ แต่นั่นเป็นระดับสูงเกินไปสำหรับการทดสอบหน่วย

— Izkata

1

@ RobertHarvey ฉันไม่ได้พูดว่าอย่าทดสอบอะไรเลย ฉันบอกว่าไม่ทดสอบหน้าหน่วยคงที่

— Jon Strayer

@ JonStrayer: TDD'ers มักจะถือ TDD เป็นยาแก้โรคทุกชนิดที่มีมนต์ขลังสำหรับการออกแบบ; ฉันขอโทษถ้านั่นไม่ใช่สิ่งที่คุณหมายถึง :)

— Robert Harvey

32

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

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

แทบเป็นไปไม่ได้เลยที่จะตอบคำถามเหล่านี้ใน IMO ทั่วไป

ฉันคิดว่ามันสำคัญกว่าที่จะรักษาความสามารถในการทดสอบในกรณีที่คุณลักษณะบางอย่างกลายเป็นสิ่งที่สำคัญกว่าที่คุณรับรู้

— ดั๊กต.
แหล่งที่มา

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

— Gordon Gustafson

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

— Michael Durrant

8

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

— Bruce Ediger
แหล่งที่มา

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

— Matteo Pagliazzi

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

— Bruce Ediger

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

— deworde

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

— Andy

3

ใช่คุณควรทดสอบทุกอย่าง ...

คุณไม่จำเป็นต้องเขียนแบบทดสอบอัตโนมัติสำหรับทุกสิ่ง สำหรับหน้าเว็บสแตติกของคุณให้ดูที่การใช้ Selenium http://seleniumhq.org/เพื่อให้แน่ใจว่าสิ่งต่าง ๆ นั้นถูกต้อง

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

— Schleis
แหล่งที่มา

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

— Schleis

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

— Andy

2

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

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

— ไม่มีโอกาส
แหล่งที่มา

2

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

— Chriseyre2000
แหล่งที่มา

2

ดังที่คนอื่น ๆ พูดถึงในการทดสอบ Ruby on Rails มันมีความสำคัญมากกว่าภาษาอื่น ๆ นี่คือสาเหตุที่ขาดคอมไพเลอร์

ภาษาเช่นDelphi , C ++, VB.NET , ฯลฯ ... เป็นภาษาที่คอมไพล์และคอมไพเลอร์ของคุณจะรับความผิดพลาดจำนวนมากเช่นความผิดพลาดในการโทรไปยังเมธอด ใน Ruby on Rails คุณจะรู้ว่ามีการพิมพ์ผิดหรือผิดพลาดในรหัสของคุณหากมีการเรียกใช้บรรทัดของรหัสนั้นหรือคุณใช้ IDE ที่แสดงคำเตือนแบบภาพ

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

ฉันพบว่าไรอันเบตส์Rails Castบนฉันทดสอบเป็นที่ทรงคุณค่าให้ฉันและมันไฮไลต์ความเรียบง่ายของ TBDD ถ้าทำอย่างถูกต้อง

— jamesc
แหล่งที่มา

1

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

— wessiyad
แหล่งที่มา

2

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

— Matteo Pagliazzi

1

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

— wessiyad

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

— Erik Reppen

0

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

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

แต่โซ่ยักษ์ใหญ่ของการพึ่งพาการเชื่อมโยงที่คาดเดาไม่ได้เป็นผลิตภัณฑ์ของการออกแบบเส็งเคร็ง?

แล้วมันคืออะไร?

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

"โปรแกรมไปยังส่วนต่อประสานไม่ใช่การใช้งาน"

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

และ:

"ชอบองค์ประกอบของวัตถุเหนือการสืบทอดคลาส"

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

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

— Erik Reppen
แหล่งที่มา

-1

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

มันอาจไม่แสดงผล
มันอาจแสดงผลไม่ถูกต้อง
JS อาจไม่โหลด
เส้นทางสำหรับรูปภาพอาจไม่ทำงาน
ลิงก์อาจเสียหาย

ส่วนตัวผมขอแนะนำ:

เขียนการทดสอบซีลีเนียม [1] ที่ตรวจสอบหนึ่งสายที่คุณคาดหวังในหน้า (ใกล้ด้านล่างถ้าเป็นไปได้) นี้ตรวจสอบว่ามันแสดงผล
ตรวจสอบว่าไม่มีข้อผิดพลาด JS (ฉันคิดว่าซีลีเนียมอนุญาตสิ่งนี้)
รันหน้าสแตติกผ่านตัวตรวจสอบความถูกต้องของ HTML และหากเป็นไปได้ตัวตรวจสอบลิงก์
ฉันไม่พบเครื่องมือที่ฉันต้องการตรวจสอบ JS แต่คุณอาจประสบความสำเร็จกับ jslint หรือ jshint

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

— Paul Biggar
แหล่งที่มา

-1

เพียงเพิ่มคำตอบที่ยอดเยี่ยมทั้งหมดแล้วนี่คือความคิดของฉันเกี่ยวกับสิ่งที่จะทดสอบและสิ่งที่ไม่ทดสอบ:

ทำแบบทดสอบ:

ตรรกะทางธุรกิจ
แอปพลิเคชันตรรกะ
ฟังก์ชั่น
พฤติกรรม,
ดังนั้นทุกอย่างยกเว้นจริงๆ:

อย่าทดสอบ:

ค่าคงที่
การเสนอ

ดังนั้นจึงไม่มีประเด็นที่จะมีการทดสอบที่บอกว่า:

assert wibble = 3

และรหัสบางอย่างที่บอกว่า

wibble = 3

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

ดังนั้นคุณถามว่า "ฉันควรทดสอบหน้าคงที่" และคำตอบคือ: คุณทดสอบพวกเขาตราบเท่าที่พวกเขาเป็นส่วนหนึ่งของการทำงานของเว็บไซต์ตรรกะทางธุรกิจหรือพฤติกรรมของคุณ

ดังนั้นในแอปของเราเรามีการทดสอบที่ตรวจสอบว่าข้อกำหนดและเงื่อนไขพร้อมใช้งานจากทุกส่วนของเว็บไซต์ - สำหรับผู้ใช้ที่ไม่ระบุชื่อสำหรับผู้ใช้ที่เข้าสู่ระบบจากแผงควบคุมภายในหน้าจอแอป ฯลฯ เพียงตรวจสอบว่ามี ลิงก์ที่เรียกว่า "ข้อกำหนดและเงื่อนไข" ในแต่ละหน้าว่าลิงก์ใช้งานได้และจากนั้นการทดสอบก็บอกว่าเมื่อมันมาถึงหน้าเว็บมัน "ดูเหมือนว่า" Ts & Cs - เพียงพอที่จะทำให้คุณมั่นใจว่ามันเป็นหน้าที่ถูกต้อง โดยไม่ต้อง "ทดสอบค่าคงที่" หรือ "ทดสอบงานนำเสนอ" ... ดังนั้นคุณสามารถตรวจสอบว่าข้อความนั้นถูกต้องตัวอย่างเช่นโดยไม่ตรวจสอบขนาดตัวอักษรหรือรูปแบบข้อความโดยเฉพาะ ...

— hwjp
แหล่งที่มา