การทดสอบคำขอ HTTP: เครื่องมือเอาตัวรอดของนักพัฒนา

จะทำอย่างไรเมื่อชุดทดสอบไม่สามารถทำได้

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

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

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

การทดสอบอัตโนมัติ

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

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

การทดสอบหน่วย

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

 test “should return active users” do active_user = create(:user, active: true) non_active_user = create(:user, active: false) result = User.active assert_equal result, [active_user] end

การทดสอบการทำงาน

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

หมายเหตุ: ตัวอย่างทั้งหมดของเราอยู่ใน Ruby

 test "should get index" do get :index assert_response :success assert_not_nil assigns(:object) end

การทดสอบบูรณาการ

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

 test "login and browse site" do # login via https https! get "/login" assert_response :success post_via_redirect "/login", username: users(:david).username, password: users(:david).password assert_equal '/welcome', path assert_equal 'Welcome david!', flash[:notice] https!(false) get "/articles/all" assert_response :success assert assigns(:articles) end

การทดสอบในโลกอุดมคติ

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

• รับประกันคุณภาพแอปพลิเคชันทั้งหมดของคุณโดยใช้ความพยายามของมนุษย์น้อยที่สุด
• ระบุจุดบกพร่องได้ง่ายขึ้นเพราะคุณรู้ว่าโค้ดของคุณขาดจากความล้มเหลวในการทดสอบที่ใด
• สร้างเอกสารอัตโนมัติสำหรับรหัสของคุณ
• หลีกเลี่ยง 'การเข้ารหัสอาการท้องผูก' ซึ่งตามที่เพื่อนบางคนใน Stack Overflow เป็นวิธีพูดตลกๆ ว่า “เมื่อคุณไม่รู้ว่าจะเขียนอะไรต่อไป หรือมีงานที่น่ากลัวอยู่ตรงหน้า ให้เริ่มด้วยการเขียนเล็กๆ น้อยๆ ”

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

การทดสอบในโลกแห่งความจริง

แม้ว่าการทดสอบทั้งสามประเภทจะมีข้อดี แต่ก็ไม่ได้ถูกเขียนขึ้นในโครงการส่วนใหญ่ ทำไม? ให้ฉันทำลายมันลง:

เวลา/กำหนดเวลา

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

ปัญหาลูกค้า

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

หรืออาจเป็นเรื่องง่ายๆ เหมือนกับที่ลูกค้าไม่มีงบประมาณที่จะจ่ายสำหรับเวลาพิเศษที่จำเป็นในการดำเนินการทดสอบเหล่านี้

ขาดความรู้

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

'งานเยอะมาก'

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

สุดท้าย แต่ไม่ท้ายสุด ข้อสอบเขียนยาก และนักเรียนวิทยาศาสตร์คอมพิวเตอร์ไม่ได้รับการฝึกฝน

โอ้ และการปรับโครงสร้างใหม่ด้วยการทดสอบหน่วยก็ไม่สนุก

ความแตกต่างในความคิดเห็น

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

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

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

แต่คุณต้องการการทดสอบบางอย่าง

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

สิ่งที่ฉันใช้แทน

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

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

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

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

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

ในทางปฏิบัติ: การทดสอบด้วยคำขอ HTTP

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

ตัวอย่างเช่น หากเราต้องเขียนการทดสอบข้างต้น (การทดสอบที่กำลังมองหาเนื้อหาเฉพาะและข้อผิดพลาดร้ายแรง) ด้วยคำขอ HTTP แทน (ใน Ruby) การทดสอบจะเป็นดังนี้:

 # testing for fatal error http_code = `curl -X #{route[:method]} -s -o /dev/null -w "%{http_code}" #{Rails.application.routes.url_helpers.articles_url(host: 'localhost', port: 3000) }` if http_code !~ /200/ return “articles_url returned with #{http_code} http code.” end # testing for content active_user = create(:user, name: “user1”, active: true) non_active_user = create(:user, name: “user2”, active: false) content = `curl #{Rails.application.routes.url_helpers.active_user_url(host: 'localhost', port: 3000) }` if content !~ /#{active_user.name}/ return “Content mismatch active user #{active_user.name} not found in text body” #You can customise message to your liking end if content =~ /#{non_active_user.name}/ return “Content mismatch non active user #{active_user.name} found in text body” #You can customise message to your liking end

เส้น curl -X #{route[:method]} -s -o /dev/null -w "%{http_code}" #{Rails.application.routes.url_helpers.articles_url(host: 'localhost', port: 3000) } ครอบคลุมกรณีทดสอบจำนวนมาก วิธีใดก็ตามที่ทำให้เกิดข้อผิดพลาดในหน้าของบทความจะถูกจับที่นี่ ดังนั้นจึงครอบคลุมโค้ดหลายร้อยบรรทัดในการทดสอบครั้งเดียว

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

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

 ids = Article.all.select { |post| `curl -s -o /dev/null -w “%{http_code}” #{Rails.application.routes.url_helpers.article_url(post, host: 'localhost', port: 3000) }`.to_i != 200).map(&:id) return ids

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

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

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

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

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

ทดสอบหนึ่ง

ตรวจสอบว่าหน้ากลับมาโดยไม่มีข้อผิดพลาดร้ายแรง

สังเกตว่าฉันสร้างรายการปลายทางทั้งหมดสำหรับ Post และทำซ้ำเพื่อตรวจสอบว่ามีการแสดงผลแต่ละหน้าโดยไม่มีข้อผิดพลาดอย่างไร สมมติว่าทุกอย่างเป็นไปด้วยดี และแสดงหน้าเว็บทั้งหมดแล้ว คุณจะเห็นสิ่งนี้ในเทอร์มินัล: ➜ sample_app git:(master) ✗ ruby test/http_request/post_test.rb List of failed url(s) -- []

หากหน้าใดไม่แสดงผล คุณจะเห็นสิ่งนี้ (ในตัวอย่างนี้ หน้า posts/index page มีข้อผิดพลาดและไม่แสดงผล): ➜ sample_app git:(master) ✗ ruby test/http_request/post_test.rb List of failed url(s) -- [{:url=>”posts_url”, :params=>[], :method=>”GET”, :http_code=>”500”}]

ทดสอบสอง

ยืนยันว่าเนื้อหาที่คาดหวังทั้งหมดอยู่ที่นั่น:

หากพบเนื้อหาทั้งหมดที่เราคาดหวังในหน้า ผลลัพธ์จะเป็นดังนี้ (ในตัวอย่างนี้ เราตรวจสอบให้แน่ใจว่า posts/:id มีชื่อโพสต์ คำอธิบาย และสถานะ): ➜ sample_app git:(master) ✗ ruby test/http_request/post_test.rb List of content(s) not found on Post#show page with post id: 1 -- []

หากไม่พบเนื้อหาที่คาดหวังบนหน้า (ในที่นี้ เราคาดว่าหน้าจะแสดงสถานะของโพสต์ - 'ใช้งานอยู่' หากโพสต์มีการใช้งานอยู่ 'ปิดการใช้งาน' หากโพสต์ถูกปิดใช้งาน) ผลลัพธ์จะเป็นดังนี้: ➜ sample_app git:(master) ✗ ruby test/http_request/post_test.rb List of content(s) not found on Post#show page with post id: 1 -- [“Active”]

ทดสอบสาม

ตรวจสอบว่าหน้าแสดงผลในชุดข้อมูลทั้งหมด (ถ้ามี):

หากหน้าเว็บทั้งหมดแสดงผลโดยไม่มีข้อผิดพลาด เราจะได้รายการที่ว่างเปล่า: ➜ sample_app git:(master) ✗ ruby test/http_request/post_test.rb List of post(s) with error in rendering -- []

หากเนื้อหาของบันทึกบางรายการมีปัญหาในการแสดงผล (ในตัวอย่างนี้ หน้าเว็บที่มี ID 2 และ 5 กำลังแสดงข้อผิดพลาด) ผลลัพธ์จะมีลักษณะดังนี้: ➜ sample_app git:(master) ✗ ruby test/http_request/post_test.rb List of post(s) with error on rendering -- [2,5]

หากคุณต้องการเล่นซอกับโค้ดสาธิตด้านบน นี่คือโครงการ github ของฉัน

ดังนั้นไหนดีกว่ากัน? มันขึ้นอยู่กับ…

การทดสอบคำขอ HTTP อาจเป็นทางออกที่ดีที่สุดของคุณหาก:

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

การทดสอบแบบดั้งเดิมเหมาะอย่างยิ่งเมื่อ:

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

ขอบคุณสำหรับการอ่านบทความ; ตอนนี้คุณควรมีวิธีการทดสอบที่คุณสามารถตั้งค่าเริ่มต้นได้ ซึ่งคุณสามารถวางใจได้เมื่อถึงเวลา