คำถามติดแท็ก mocking

ฉันเข้าใจถึงคุณค่าของการทดสอบอัตโนมัติและใช้งานได้ทุกที่ที่ปัญหามีการระบุไว้อย่างดีพอที่จะทำให้เกิดกรณีทดสอบที่ดี ฉันสังเกตเห็นว่าบางคนที่นี่และใน StackOverflow เน้นการทดสอบเพียงหน่วยเดียวไม่ใช่การพึ่งพา ที่นี่ฉันไม่เห็นประโยชน์ การเยาะเย้ย / การขัดถูเพื่อหลีกเลี่ยงการทดสอบการพึ่งพาเพิ่มความซับซ้อนให้กับการทดสอบ มันเพิ่มความยืดหยุ่นในการประดิษฐ์ / การแยกชิ้นส่วนข้อกำหนดในรหัสการผลิตของคุณเพื่อรองรับการเยาะเย้ย (ฉันไม่เห็นด้วยกับใครก็ตามที่บอกว่าสิ่งนี้ส่งเสริมการออกแบบที่ดีเขียนโค้ดพิเศษแนะนำสิ่งต่าง ๆ เช่นกรอบการฉีดพึ่งพาหรือเพิ่มความซับซ้อนให้กับโค้ดเบสของคุณเพื่อให้สิ่งที่ยืดหยุ่น / pluggable / extensible / decoupled การออกแบบที่ดี.) ประการที่สองการทดสอบการพึ่งพาหมายความว่ารหัสระดับต่ำที่สำคัญที่ใช้ในทุกที่ได้รับการทดสอบด้วยอินพุตนอกเหนือจากที่ผู้เขียนการทดสอบคิดอย่างชัดเจน ฉันได้พบข้อบกพร่องมากมายในการทำงานระดับต่ำโดยใช้การทดสอบหน่วยในการทำงานระดับสูงโดยไม่ต้องเยาะเย้ยการทำงานระดับต่ำที่มันขึ้นอยู่กับ โดยหลักการแล้วสิ่งเหล่านี้จะถูกค้นพบโดยการทดสอบหน่วยสำหรับฟังก์ชั่นระดับต่ำ แต่กรณีพลาดมักเกิดขึ้นเสมอ ด้านนี้คืออะไร? เป็นสิ่งสำคัญจริง ๆ ที่การทดสอบหน่วยไม่ได้ทดสอบการพึ่งพาของมันด้วย? ถ้าเป็นเช่นนั้นทำไม แก้ไข: ฉันสามารถเข้าใจคุณค่าของการเยาะเย้ยการพึ่งพาภายนอกเช่นฐานข้อมูลเครือข่ายบริการเว็บ ฯลฯ (ขอบคุณ Anna Lear สำหรับการจูงใจให้ฉันชี้แจงสิ่งนี้) ฉันหมายถึงการพึ่งพาภายในเช่นคลาสอื่น ๆ ฟังก์ชั่นคงที่ ฯลฯ ที่ไม่มีการพึ่งพาภายนอกโดยตรง

103 testing  unit-testing  dependency-injection  mocking 

คุณมีคลาส X และคุณเขียนการทดสอบหน่วยบางอย่างที่ตรวจสอบพฤติกรรม X1 นอกจากนี้ยังมีคลาส A ซึ่งใช้ X เป็นตัวอ้างอิง เมื่อคุณเขียนการทดสอบหน่วยสำหรับ A คุณจำลอง X ในคำอื่น ๆ ในขณะที่การทดสอบหน่วย A คุณตั้งค่า (สมมุติ) พฤติกรรมของจำลองของ X ให้เป็น X1 เวลาผ่านไปผู้คนใช้ระบบของคุณต้องการการเปลี่ยนแปลง X วิวัฒนาการ: คุณแก้ไข X เพื่อแสดงพฤติกรรม X2 เห็นได้ชัดว่าการทดสอบหน่วยสำหรับ X จะล้มเหลวและคุณจะต้องปรับตัว แต่อะไรกับ A? การทดสอบหน่วยสำหรับ A จะไม่ล้มเหลวเมื่อปรับเปลี่ยนพฤติกรรมของ X (เนื่องจากการเยาะเย้ยของ X) วิธีการตรวจสอบว่าผลลัพธ์ของ A จะแตกต่างกันเมื่อทำงานด้วย X "จริง" (แก้ไข) X ฉันคาดหวังคำตอบตามบรรทัดของ: "นั่นไม่ใช่จุดประสงค์ของการทดสอบหน่วย" …

98 unit-testing  testing  mocking 

ฉันได้พบว่ามีเพียง 3 วิธีในการทดสอบหน่วยอ้างอิง (จำลอง / ต้นขั้ว) ที่คงที่ใน C # .NET: ไฝ TypeMock JustMock เนื่องจากว่าสองสิ่งนี้ไม่ฟรีและไม่มีการปล่อยรุ่น 1.0 การเยาะเย้ยสิ่งคงไม่ง่ายเกินไป นั่นทำให้วิธีการคงที่และ "ความชั่วร้าย" (ในแง่การทดสอบหน่วย) หรือไม่? และถ้าเป็นเช่นนั้นทำไม resharper จึงต้องการให้ฉันทำอะไรที่คงที่ (การสมมติว่า resharper ไม่ได้เป็น "ความชั่วร้าย" ด้วย) ชี้แจง: ฉันกำลังพูดถึงสถานการณ์เมื่อคุณต้องการทดสอบหน่วยวิธีและวิธีการที่เรียกว่าวิธีการคงที่ในหน่วย / ระดับที่แตกต่างกัน โดยคำจำกัดความส่วนใหญ่ของการทดสอบหน่วยหากคุณเพียงให้วิธีการทดสอบเรียกวิธีการคงที่ในหน่วย / ชั้นเรียนอื่น ๆ แล้วคุณไม่ได้ทดสอบหน่วยคุณกำลังทดสอบบูรณาการ (มีประโยชน์ แต่ไม่ใช่การทดสอบหน่วย)

85 c#  unit-testing  static-methods  mocking 

ตามที่ผมเข้าใจจุดของการทดสอบหน่วยคือการทดสอบหน่วยของรหัสในการแยก หมายความว่า: พวกเขาไม่ควรทำลายโดยการเปลี่ยนแปลงรหัสที่ไม่เกี่ยวข้องใดๆ ใน codebase การทดสอบหน่วยเดียวควรทำลายข้อบกพร่องในหน่วยการทดสอบซึ่งตรงข้ามกับการทดสอบการรวม (ซึ่งอาจแบ่งเป็นฮีป) ทั้งหมดนี้แสดงถึงว่าควรมีการเยาะเย้ยจากภายนอกหน่วยทดสอบ และฉันหมายถึงการพึ่งพาภายนอกทั้งหมดไม่เพียง แต่ "เลเยอร์นอก" เช่นระบบเครือข่ายระบบไฟล์ฐานข้อมูล ฯลฯ นี้นำไปสู่ข้อสรุปเชิงตรรกะที่แทบทุกหน่วยทดสอบความต้องการที่จะเยาะเย้ย ในทางกลับกันการค้นหาอย่างรวดเร็วของ Google เกี่ยวกับการเยาะเย้ยเผยให้เห็นบทความมากมายที่อ้างว่า "การเยาะเย้ยเป็นกลิ่นรหัส" และส่วนใหญ่ควรหลีกเลี่ยง (แม้ว่าจะไม่สมบูรณ์) ตอนนี้สำหรับคำถาม การทดสอบหน่วยควรเขียนอย่างถูกต้องอย่างไร? เส้นแบ่งระหว่างพวกเขากับการทดสอบการรวมอยู่ตรงไหน? อัปเดต 1 โปรดพิจารณารหัสหลอกต่อไปนี้: class Person { constructor(calculator) {} calculate(a, b) { const sum = this.calculator.add(a, b); // do some other stuff with the `sum` } } การทดสอบที่ทดสอบPerson.calculateวิธีการโดยไม่มีการเยาะเย้ยการCalculatorพึ่งพา …

80 unit-testing  testing  integration-tests  mocking  stub 

ฉันมีวิธีส่วนตัวในชั้นทดสอบของฉันที่สร้างBarวัตถุที่ใช้กันทั่วไป คอนBarสตรัคsomeMethod()วิธีการโทรในวัตถุที่เยาะเย้ยของฉัน: private @Mock Foo mockedObject; // My mocked object ... private Bar getBar() { Bar result = new Bar(mockedObject); // this calls mockedObject.someMethod() } ในบางวิธีการทดสอบของฉันฉันต้องการตรวจสอบsomeMethodก็ถูกเรียกใช้โดยการทดสอบนั้น สิ่งต่อไปนี้: @Test public void someTest() { Bar bar = getBar(); // do some things verify(mockedObject).someMethod(); // <--- will fail } สิ่งนี้ล้มเหลวเนื่องจากวัตถุที่เยาะเย้ยได้someMethodเรียกใช้สองครั้ง ฉันไม่ต้องการวิธีการทดสอบของฉันจะดูแลเกี่ยวกับผลข้างเคียงของฉันgetBar()วิธีจึงจะเหมาะสมที่จะตั้งค่าวัตถุจำลองของฉันในตอนท้ายของgetBar()? private Bar …

68 java  mocking 

ฉันกำลังทำงานกับระบบต่อไปนี้: Network Data Feed -> Third Party Nio Library -> My Objects via adapter pattern เมื่อเร็ว ๆ นี้เรามีปัญหาเมื่อฉันอัปเดตเวอร์ชันของห้องสมุดที่ฉันใช้ซึ่งทำให้เกิดการประทับเวลา (ซึ่งห้องสมุดของบุคคลที่สามกลับมาเป็นlong) ซึ่งจะเปลี่ยนจากมิลลิวินาทีหลังจากยุคเป็นนาโนวินาทีหลังจากยุค ปัญหา: หากฉันเขียนการทดสอบที่จำลองวัตถุของห้องสมุดบุคคลที่สามการทดสอบของฉันจะผิดถ้าฉันทำผิดเกี่ยวกับวัตถุของห้องสมุดบุคคลที่สาม ตัวอย่างเช่นฉันไม่ทราบว่าการประทับเวลาเปลี่ยนความแม่นยำซึ่งส่งผลให้จำเป็นต้องเปลี่ยนการทดสอบหน่วยเนื่องจากการจำลองของฉันคืนข้อมูลผิด นี่ไม่ใช่ข้อผิดพลาดในไลบรารีมันเกิดขึ้นเพราะฉันพลาดบางสิ่งบางอย่างในเอกสาร ปัญหาคือฉันไม่แน่ใจเกี่ยวกับข้อมูลที่มีอยู่ในโครงสร้างข้อมูลเหล่านี้เพราะฉันไม่สามารถสร้างข้อมูลจริงได้หากไม่มีฟีดข้อมูลจริง วัตถุเหล่านี้มีขนาดใหญ่และซับซ้อนและมีข้อมูลจำนวนมากแตกต่างกัน เอกสารสำหรับห้องสมุดบุคคลที่สามไม่ดี คำถาม: ฉันจะตั้งค่าการทดสอบเพื่อทดสอบพฤติกรรมนี้ได้อย่างไร ฉันไม่แน่ใจว่าฉันสามารถแก้ปัญหานี้ได้ในการทดสอบหน่วยเพราะการทดสอบนั้นผิดพลาดได้ง่าย นอกจากนี้ระบบรวมมีขนาดใหญ่และซับซ้อนและง่ายต่อการพลาดบางสิ่งบางอย่าง ตัวอย่างเช่นในสถานการณ์ข้างต้นฉันได้ปรับการจัดการการประทับเวลาในหลายสถานที่อย่างถูกต้อง แต่ฉันพลาดหนึ่งในนั้น ระบบดูเหมือนจะทำสิ่งที่ถูกต้องเป็นส่วนใหญ่ในการทดสอบการรวมระบบของฉัน แต่เมื่อฉันปรับใช้กับการผลิต (ซึ่งมีข้อมูลมากขึ้น) ปัญหาก็ชัดเจน ตอนนี้ฉันไม่มีกระบวนการทดสอบการรวมเข้าด้วยกัน การทดสอบนั้นสำคัญ: พยายามทำให้การทดสอบหน่วยดีเพิ่มการทดสอบเพิ่มเติมเมื่อสิ่งแตกหักจากนั้นปรับใช้กับเซิร์ฟเวอร์ทดสอบของฉันและตรวจสอบให้แน่ใจว่าสิ่งต่าง ๆ ดูมีเหตุผล ปัญหาการประทับเวลานี้ผ่านการทดสอบหน่วยเนื่องจาก mocks ถูกสร้างขึ้นผิดจากนั้นจะผ่านการทดสอบการรวมเนื่องจากไม่ได้ทำให้เกิดปัญหาที่ชัดเจนและทันที ฉันไม่มีแผนกควบคุมคุณภาพ

34 testing  object-oriented-design  development-process  mocking  adapter 

ขณะนี้ฉันอยู่ในชั้นเรียนสำหรับการทดสอบซอฟต์แวร์ที่สำหรับโครงการภาคการศึกษาของเราเราต้องทำการทดสอบหลายประเภทเช่นการทดสอบหน่วยและการทดสอบการรวม สำหรับการทดสอบการรวมตัวอาจารย์กล่าวว่าจะใช้ห้องสมุด mocks และการเยาะเย้ย (เช่น EasyMock และ Mockito) สำหรับการทดสอบการรวมกลุ่มของเรา ฉันเริ่มสับสนแล้ว การทดสอบการรวมเป็นการทดสอบนอกชั้นเรียนโมดูลบริการ ฯลฯ เหตุใด mocks และ stubs จึงเหมาะสมที่จะใช้ในการทดสอบการรวมหากคุณกำลังทดสอบคลาสและบริการที่หลากหลาย

24 unit-testing  testing  integration-tests  mocking 

สมมติว่าฉันมีชั้นเรียน (ยกโทษให้ตัวอย่างที่ออกแบบและการออกแบบที่ไม่ดีของมัน): class MyProfit { public decimal GetNewYorkRevenue(); public decimal GetNewYorkExpenses(); public decimal GetNewYorkProfit(); public decimal GetMiamiRevenue(); public decimal GetMiamiExpenses(); public decimal GetMiamiProfit(); public bool BothCitiesProfitable(); } (หมายเหตุเมธอด GetxxxRevenue () และ GetxxxExpenses () มีการขึ้นต่อกันที่ถูกสตับออก) ตอนนี้ฉันกำลังทดสอบหน่วย BothCitiesProfitable () ซึ่งขึ้นอยู่กับ GetNewYorkProfit () และ GetMiamiProfit () การรับ GetNewYorkProfit () และ GetMiamiProfit () ดีไหม …

22 unit-testing  mocking  stub 

ฉันดิ้นรนกับปัญหาที่น่ารำคาญมากขึ้นเกี่ยวกับการทดสอบหน่วยของเราที่เรากำลังนำไปใช้ในทีมของฉัน เรากำลังพยายามเพิ่มการทดสอบหน่วยในรหัสดั้งเดิมที่ไม่ได้ออกแบบมาอย่างดีและในขณะที่เราไม่ได้มีปัญหาใด ๆ กับการเพิ่มการทดสอบจริง ๆ เราเริ่มที่จะต่อสู้กับการทดสอบที่เกิดขึ้น เป็นตัวอย่างของปัญหาสมมติว่าคุณมีวิธีการที่เรียก 5 วิธีอื่น ๆ เป็นส่วนหนึ่งของการดำเนินการ การทดสอบสำหรับวิธีนี้อาจเป็นการยืนยันว่าลักษณะการทำงานที่เกิดขึ้นเป็นผลมาจากวิธีการหนึ่งใน 5 วิธีการอื่นที่เรียกว่า ดังนั้นเนื่องจากการทดสอบหน่วยควรล้มเหลวด้วยเหตุผลเดียวและเหตุผลเดียวเท่านั้นคุณต้องการกำจัดปัญหาที่อาจเกิดขึ้นจากการเรียก 4 วิธีการอื่น ๆ เหล่านี้และเยาะเย้ยพวกเขาออก ที่ดี! การทดสอบหน่วยดำเนินการวิธีการเยาะเย้ยจะถูกละเว้น (และพฤติกรรมของพวกเขาสามารถยืนยันได้ว่าเป็นส่วนหนึ่งของการทดสอบหน่วยอื่น ๆ ) และการตรวจสอบใช้งานได้ แต่มีปัญหาใหม่ - การทดสอบหน่วยมีความรู้อย่างใกล้ชิดว่าคุณยืนยันพฤติกรรมและการเปลี่ยนแปลงลายเซ็นใด ๆ ของ 4 วิธีอื่น ๆ ในอนาคตหรือวิธีการใหม่ใด ๆ ที่จำเป็นต้องเพิ่มใน 'วิธีการหลัก' จะ ส่งผลให้ต้องเปลี่ยนการทดสอบหน่วยเพื่อหลีกเลี่ยงความล้มเหลวที่เป็นไปได้ โดยธรรมชาติแล้วปัญหาสามารถลดลงได้บ้างเพียงแค่มีวิธีการมากขึ้นที่จะทำให้พฤติกรรมน้อยลง แต่ฉันหวังว่าอาจจะมีวิธีการแก้ปัญหาที่หรูหรากว่านี้ นี่คือตัวอย่างการทดสอบหน่วยที่จับปัญหา ในฐานะที่เป็นโน้ตย่อ 'MergeTests' เป็นคลาสการทดสอบหน่วยที่สืบทอดจากคลาสที่เรากำลังทดสอบและแทนที่พฤติกรรมตามต้องการ นี่คือ 'รูปแบบ' ที่เราใช้ในการทดสอบของเราเพื่อให้เราสามารถแทนที่การโทรไปยังคลาส / การอ้างอิงภายนอก …

21 c#  testing  unit-testing  mocking 

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

16 unit-testing  tdd  integration-tests  mocking 

สมมติว่ามีอินเทอร์เฟซ IReader การนำไปใช้ของตัวอ่าน IReader อินเตอร์เฟส ReaderImplementation และคลาส ReaderConsumer ที่ใช้และประมวลผลข้อมูลจากเครื่องอ่าน public interface IReader { object Read() } การดำเนินงาน public class ReaderImplementation { ... public object Read() { ... } } ผู้บริโภค: public class ReaderConsumer() { public string location // constructor public ReaderConsumer() { ... } // read some data public object …

15 mocking  code-smell 

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

15 mocking 

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

15 testing  tdd  anti-patterns  object-oriented-design  mocking 

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

15 unit-testing  mocking 

ฉันวนเวียนวนไปรอบ ๆ เพื่อหาวิธีที่ดีที่สุดในการทดสอบหน่วยห้องสมุดลูกค้า API ที่ฉันกำลังพัฒนา ห้องสมุดที่มีClientระดับซึ่งโดยทั่วไปมี 1: การทำแผนที่ 1 กับ API และอีกชั้นซึ่งมีอินเตอร์เฟซที่ใช้งานง่ายขึ้นกว่าด้านบนของWrapperClient Wrapper --> Client --> External API ก่อนอื่นฉันเขียนการทดสอบทั้งคู่ClientและWrapperทดสอบอย่างมีประสิทธิภาพว่าจะส่งต่อไปยังฟังก์ชันที่เหมาะสมของสิ่งที่ทำงาน ( WrapperทำงานClientและClientทำงานกับการเชื่อมต่อ HTTP) ฉันเริ่มรู้สึกอึดอัดกับสิ่งนี้เพราะฉันรู้สึกว่าฉันกำลังทดสอบการใช้งานคลาสเหล่านี้มากกว่าที่จะเป็นส่วนต่อประสาน ในทางทฤษฎีฉันสามารถเปลี่ยนคลาสให้มีการใช้งานที่ถูกต้องสมบูรณ์แบบอื่น แต่การทดสอบของฉันจะล้มเหลวเพราะฟังก์ชั่นที่ฉันคาดว่าจะเรียกไม่ถูกเรียก ฟังดูเหมือนการทดสอบที่เปราะบางสำหรับฉัน หลังจากนี้ฉันคิดถึงอินเทอร์เฟซของคลาส การทดสอบควรตรวจสอบว่าชั้นเรียนทำงานตามที่ตั้งใจจริงมากกว่าที่จะทำ แล้วฉันจะทำสิ่งนี้ได้อย่างไร สิ่งแรกที่ควรคำนึงถึงคือการขัดคำขอ API ภายนอก อย่างไรก็ตามฉันกังวลใจเกี่ยวกับการขยายบริการภายนอก ตัวอย่างของ API ที่ถูก stubbed จำนวนมากที่ฉันเคยเห็นเพียงแค่ให้การตอบกลับสำเร็จรูปซึ่งดูเหมือนเป็นวิธีที่ง่ายมากที่จะทดสอบว่าโค้ดของคุณทำงานได้อย่างถูกต้องกับ API ปลอมของคุณ ทางเลือกคือการเยาะเย้ยบริการซึ่งเป็นไปไม่ได้และจะต้องได้รับการปรับปรุงให้ทันสมัยอยู่เสมอเมื่อใดก็ตามที่มีการเปลี่ยนแปลงการบริการจริง - ซึ่งรู้สึกว่าเกินความเป็นจริงและเสียเวลา ในที่สุดฉันอ่านข้อความนี้จากคำตอบอื่นของโปรแกรมเมอร์ SE : งานของไคลเอนต์ API ระยะไกลคือการออกสายบางอย่าง - …

14 unit-testing  testing  api  mocking  adapter