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


16

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

function retrieve_related_data(id)
{
  query = "[potentially long, syntactically complex query that
            uses param id to get some data]";
  results = api_wrapper.query(query);
  return results;
}

ตัวอย่างที่เป็นรูปธรรมมากขึ้นด้วย API ที่สร้างขึ้น:

function retrieveLifeSupportingObjectsWithinRegion(id)
{
  query = "
    within region(" + id + ") as r
    find objects matching hydration>0 and temp_range has 75
    send name, id, relative(position, r)        
  ";
  results = astronomicalObjectApiWrapper.query(query);
  return results;
}

The query is in a syntax custom to the API and is complex and there are multiple ways to achieve the same or similar results. The purpose of the function is not to get data identified by id but to find a subset of other data based on a fuzzy relationship to the data identified by id that also meets a few other requirements. The other requirements are always the same regardless of id but may change over time as the system is modified. For example, if the example api added support for gravity information, we may want to change the query to also use gravity to refine the results. Or maybe we come up with a more efficient way to check the temp range, but it doesn't change the results.

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

ตัวเลือกที่ฉันได้พิจารณา:

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

  2. ฉันสามารถส่งแบบสอบถามไปยัง API จริง แต่ผลลัพธ์ที่คาดหวังสามารถเปลี่ยนแปลงได้ตลอดเวลาเมื่อข้อมูลในระบบภายนอกเปลี่ยนแปลงไปนอกการควบคุมของระบบทดสอบ

  3. ฉันสามารถดูการตั้งค่าการติดตั้งทดสอบของ API จริงเพื่อควบคุมข้อมูลที่มี แต่นั่นเป็นความพยายามอย่างมาก

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


ฉันคิดว่านี่เป็นการทดสอบหน่วย แต่บางทีมันอาจเป็นการทดสอบการรวมหรือการทดสอบการยอมรับระดับต่ำ
Joshua Coady

2
เป็น API แบบอ่านอย่างเดียวหรือไม่ หรือคุณสามารถเขียนข้อมูลที่คุณสามารถตรวจสอบการอ่านของคุณได้อย่างน่าเชื่อถือ?
svidgen

คำถามนี้แตกต่างจาก "วิธีทดสอบว่า sql ของฉัน (= ไวยากรณ์ที่ซับซ้อน) ส่งคืนข้อมูล correnct หรือไม่" ด้วยฐานข้อมูลคุณมักจะมีการทดสอบการรวมสองสามอย่างที่ทดสอบ crud-sql-syntax และ mocked repository fasade เพื่อตรวจสอบ businesslogic
k3b

คำตอบ:


7

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

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

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

ทำไมฉันถึงพูดอย่างนั้น?

สิ่งที่ฉันต้องการทดสอบก็คือสำหรับรหัสอินพุตที่กำหนดชุดข้อมูลที่ถูกต้องจะถูกส่งกลับ

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

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

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

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

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

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

ฉันขอแนะนำให้ใช้เครื่องมือเพื่อจุดประสงค์ดังกล่าว มันอาจจะง่ายเหมือน:

  • คลาสที่รันเป็นการทดสอบ แต่ไม่ได้อยู่ในแผนการทดสอบ
  • เชลล์สคริปต์ + curl

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

ในกรณีใด ๆ ฟังก์ชั่นภายใต้คำถามดีคุ้มค่าการทดสอบสองชนิด:

  • การทดสอบหน่วย อย่างที่คุณพูดคุณต้อง stubb API ภายนอก แต่นั่นคือจุดประสงค์ทั้งหมดของการทดสอบหน่วย การทดสอบรหัสของเราแยกการอ้างอิง

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

หมายเหตุด้านข้าง: คำถามของคุณคล้ายกับ - คุณจะทดสอบคำสั่ง SQL ของแอพอย่างไร?

คำถามที่เกี่ยวข้อง :


1: คุณอาจสนใจคำตอบของ @ DocBrown เกี่ยวกับหัวข้อนี้


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

คำถาม OP กำลังถามวิธีทดสอบฟังก์ชันที่เรียกใช้กับ API ภายนอก แต่การอ่านข้อสงสัยของเขาดูเหมือนว่าฉันให้ความสำคัญกับการทดสอบคำถามและผลลัพธ์ของมันมากเกินไป ฉันให้คำแนะนำ 4 ข้อ: (1) ไม่ทำการทดสอบ API (2) ไม่ใช้การทดสอบการรวมเป็น workbench สำหรับปรับแต่งแบบสอบถาม ทำเครื่องมือแทน (3) กลับไปที่คำถามหลักทำการทดสอบแบบรวมและบูรณาการ แต่ไม่ตรวจสอบความถูกต้องของเนื้อหาของการตอบสนอง API (4) ถามผู้จัดการโครงการว่าพวกเขาควร / สามารถสร้างชุดทดสอบของ API ภายนอกเป็นส่วนหนึ่งของแผนการทดสอบของโครงการหรือไม่
Laiv

1
ฉันพิจารณาข้อความค้นหาเองว่า "รหัสที่เราเขียน" เป้าหมายสุดท้ายคือการทดสอบอัตโนมัติเพื่อแจ้งเตือนเราหากเราแนะนำข้อบกพร่องในรหัสของเรา เมื่อนำไปใช้กับสิ่งที่คุณพูดเกี่ยวกับคำสั่ง SQL ฉันคิดว่ามันคล้ายกับ - ฉันเดาว่าคำถามของฉันเหมือนคุณจะทดสอบได้อย่างไรว่าโค้ดของคุณทำการสืบค้น API ภายนอกในลักษณะที่ API จะตอบสนองตามที่คาดหวัง การตอบสนองเล็กน้อย) ฉันคิดว่าสิ่งที่คุณพูดนั้นคือการทดสอบนั้นออกจากหน่วยและการรวมเข้าด้วยกัน แต่ถ้าคำถามเป็นภารกิจที่สำคัญเราสามารถตั้งค่าการทดสอบอัตโนมัติอื่น ๆ แยกต่างหากเพื่อทดสอบ API ภายนอกที่ใช้งานจริง
Joshua Coady

1
IMO วิธีที่ดีที่สุดคือทำการทดสอบฟังก์ชั่นการเปลี่ยนแปลงในส่วนที่ไม่เคยเป็นจริงจะทำให้ behaivor ที่แตกต่างกันในการทดสอบการทำงานของฉันอย่างน้อยหนึ่งครั้ง UT เป็นเพียงส่วนเล็ก ๆ ในแผนการทดสอบ
Laiv

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

2

ฉันได้เห็นหน่วยตรวจสอบที่ตรวจสอบสตริงแบบสอบถามที่สร้างขึ้นตรงกับค่าที่คาดหวัง

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

ฉันคิดว่าคุณถูกต้องสำหรับตัวเลือกของคุณ 2. เรียกใช้การทดสอบการรวมกับอินสแตนซ์สด

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

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


0

ขึ้นอยู่กับ API แต่ถ้าเป็นไปได้ให้เลือก # 3 (อินสแตนซ์การทดสอบส่วนตัว)

การขัด API (ตัวเลือก # 1) เป็นตัวเลือกที่แย่ที่สุดเนื่องจากสาเหตุที่คุณกล่าวถึงการไปตามเส้นทางนี้อาจเป็นอันตรายมากกว่าดี (เสียเวลามากมาย)

การทำงานกับ API ที่แท้จริง (ตัวเลือก # 2) ทำให้การทดสอบนั้นไม่สม่ำเสมอและไม่น่าเชื่อถือและหลังจากผู้ใช้ที่เป็นเท็จเพียงไม่กี่คนก็จะหยุดใช้งาน ไม่เพียง แต่การเปลี่ยนแปลงข้อมูลเท่านั้น แต่บริการอาจหยุดทำงานเช่นกัน ในความคิดของฉันนี้คล้ายกับไม่มีการทดสอบสำหรับแบบสอบถามและอาศัยการทดสอบการรวม / ระบบเพื่อค้นหาปัญหา ที่กล่าวว่าหากข้อมูล API เปลี่ยนแปลงน้อยมากและ API เองเกือบจะหมดแล้วนี่อาจเป็นตัวเลือกที่ทำงานได้ APIs ส่วนใหญ่ไม่ตรงกับคำอธิบายนี้

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


โดยพื้นฐานแล้วคุณกำลังบอกว่าการทดสอบหน่วย (# 1) และการทดสอบการรวม (# 2) เป็นอันตรายหรือไม่ แม้ว่า # 3 อาจดูดีที่สุดในหมู่พวกเขา แต่ก็อาจจะแพงที่สุดเช่นกัน ต้องมีการปรับปรุงทุกครั้งที่มีการเปลี่ยนแปลง API หากไม่มี # 2 คุณจะไม่ทราบถึงการเปลี่ยนแปลงข้อบกพร่องที่เป็นไปได้ใน API จริงจนกว่าแอปของคุณจะอยู่ระหว่างการผลิต (สายเกินไปสำหรับมาตรการ) ตกลง # 1 ดูเหมือนไม่มีใครสนใจเพราะไม่มีบรรทัดของรหัสที่จะทดสอบ ... วันนี้ ... พรุ่งนี้รู้ได้อย่างไร ...
Laiv

ฉันกำลังบอกว่าการทดสอบที่ไม่ดีนั้นเป็นอันตรายแน่นอน การทดสอบที่ไม่สม่ำเสมอทำให้เสียเวลาและความพยายามอย่างมากและทำให้ผู้คนขาดความเชื่อมั่นในการทดสอบหน่วยโดยรวม การทดสอบที่ตัดกับการเปลี่ยนแปลงการใช้งาน (# 1) หรือเพียงแค่สุ่มเมื่อการเปลี่ยนแปลงข้อมูล (# 2) ไม่ใช่การทดสอบที่ดี
Michal Tenenberg

การทดสอบการรวมระบบไม่ได้ทดสอบข้อมูล แค่นั้นแหละ. พวกเขาไม่สามารถหยุดการทดสอบได้เพียงตรวจสอบการรวมเข้าด้วยกัน การทดสอบไม่ใช่เรื่องของศรัทธาเป็นเรื่องของการมีนิสัยที่ดีที่เพิ่มคุณค่าให้กับแอปพลิเคชัน
Laiv
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.