การทดสอบไมโครเซอร์วิสอัตโนมัติใน Docker เพื่อการบูรณาการอย่างต่อเนื่อง

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

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

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

ระบบอัตโนมัติของแนวทางนี้ทำให้เกิดปัญหาหลายประการ ซึ่งจะอธิบายวิธีแก้ปัญหาไว้ด้านล่าง:

• ข้อขัดแย้งของงานแบบขนานในโฮสต์นักเทียบท่าเดียวกัน
• ข้อขัดแย้งของตัวระบุในฐานข้อมูลระหว่างการทดสอบวนซ้ำ
• กำลังรอให้ไมโครเซอร์วิสพร้อม
• การรวมและส่งออกบันทึกไปยังระบบภายนอก
• ทดสอบคำขอ HTTP ขาออก
• การทดสอบซ็อกเก็ตเว็บ (โดยใช้ SignalR);
• ทดสอบการรับรองความถูกต้องและการอนุญาต OAuth

บทความนี้มีพื้นฐานมาจาก คำพูดของฉัน ที่งาน SECR 2019 ดังนั้นสำหรับผู้ที่ขี้เกียจอ่านหนังสือ นี่คือบันทึกคำพูด.

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

สคริปต์เดียวกันนี้รันโดยนักพัฒนาเองบนเดสก์ท็อป Windows และโดยเซิร์ฟเวอร์ Gitlab CI ภายใต้ Linux

เพื่อให้เป็นธรรม การแนะนำการทดสอบใหม่ไม่ควรต้องมีการติดตั้งเครื่องมือเพิ่มเติมบนคอมพิวเตอร์ของผู้พัฒนาหรือบนเซิร์ฟเวอร์ที่การทดสอบดำเนินการบนคอมมิต Docker แก้ปัญหานี้

การทดสอบจะต้องทำงานบนเซิร์ฟเวอร์ภายในเครื่องด้วยเหตุผลดังต่อไปนี้:

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

นอกจากนี้ ไม่พึงปรารถนาที่จะใช้ขาตั้งเนื่องจาก:

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

เกี่ยวกับโครงการและองค์กรกระบวนการ

บริษัทของเราพัฒนาไมโครเซอร์วิสเว็บแอปพลิเคชันที่ทำงานบน Docker ใน Amazon AWS cloud มีการใช้การทดสอบหน่วยในโครงการแล้ว แต่มักเกิดข้อผิดพลาดโดยตรวจไม่พบการทดสอบหน่วย จำเป็นต้องทดสอบไมโครเซอร์วิสทั้งหมดพร้อมกับฐานข้อมูลและบริการของ Amazon

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

สถาปัตยกรรมโครงการ

แอปพลิเคชันประกอบด้วยบริการมากกว่าสิบรายการ บางส่วนเขียนด้วย .NET Core และบางส่วนเขียนใน NodeJs แต่ละบริการทำงานในคอนเทนเนอร์ Docker ใน Amazon Elastic Container Service แต่ละแห่งมีฐานข้อมูล Postgres ของตัวเอง และบางแห่งก็มี Redis ด้วย ไม่มีฐานข้อมูลทั่วไป หากบริการหลายอย่างต้องการข้อมูลเดียวกัน เมื่อมีการเปลี่ยนแปลง ข้อมูลนี้จะถูกส่งไปยังแต่ละบริการเหล่านี้ผ่าน SNS (Simple Notification Service) และ SQS (Amazon Simple Queue Service) และบริการต่างๆ จะบันทึกไว้ในฐานข้อมูลแยกต่างหากของตนเอง

SQS และ SNS

SQS ช่วยให้คุณใส่ข้อความลงในคิวและอ่านข้อความจากคิวโดยใช้โปรโตคอล HTTPS

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

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

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

API เกตเวย์

บริการส่วนใหญ่ไม่สามารถเข้าถึงได้โดยตรงจากอินเทอร์เน็ต การเข้าถึงทำได้ผ่าน API Gateway ซึ่งจะตรวจสอบสิทธิ์การเข้าถึง นี่คือบริการของเราและมีการทดสอบด้วยเช่นกัน

การแจ้งเตือนแบบเรียลไทม์

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

วิธีการทดสอบที่รู้จักกันดี

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

В บทความจากไมโครซอฟต์ ขอเสนอให้ใช้ฐานข้อมูลในหน่วยความจำและปรับใช้อ็อบเจ็กต์จำลอง

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

อ็อบเจ็กต์จำลองจำลองคลาสที่พวกเขากำลังแทนที่เฉพาะในขอบเขตที่ผู้พัฒนาการทดสอบเข้าใจวิธีการทำงาน

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

เรามาดูวิธีแก้ปัญหากันดีกว่า

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

การตั้งค่าสภาพแวดล้อมการทดสอบ

ภารกิจแรกคือการปรับใช้สภาพแวดล้อมการทดสอบ ขั้นตอนที่จำเป็นในการรันไมโครเซอร์วิส:

• กำหนดค่าบริการภายใต้การทดสอบสำหรับสภาพแวดล้อมท้องถิ่น ระบุรายละเอียดสำหรับการเชื่อมต่อกับฐานข้อมูลและ AWS ในตัวแปรสภาพแวดล้อม
• เริ่ม Postgres และดำเนินการย้ายข้อมูลโดยเรียกใช้ Liquibase
  ใน DBMS เชิงสัมพันธ์ ก่อนที่จะเขียนข้อมูลลงในฐานข้อมูล คุณต้องสร้างสคีมาข้อมูล หรืออีกนัยหนึ่งคือ ตาราง เมื่ออัปเดตแอปพลิเคชัน จะต้องนำตารางไปยังแบบฟอร์มที่ใช้โดยเวอร์ชันใหม่ และโดยเฉพาะอย่างยิ่ง โดยไม่สูญเสียข้อมูล สิ่งนี้เรียกว่าการโยกย้าย การสร้างตารางในฐานข้อมูลว่างตั้งแต่แรกเป็นกรณีพิเศษของการย้ายข้อมูล การย้ายข้อมูลสามารถสร้างขึ้นในแอปพลิเคชันได้ ทั้ง .NET และ NodeJS มีเฟรมเวิร์กการโยกย้าย ในกรณีของเรา ด้วยเหตุผลด้านความปลอดภัย ไมโครเซอร์วิสจะถูกลิดรอนสิทธิ์ในการเปลี่ยนแปลงสคีมาข้อมูล และการย้ายจะดำเนินการโดยใช้ Liquibase
• เปิดตัว Amazon LocalStack นี่คือการนำบริการของ AWS ไปใช้งานที่บ้าน มีอิมเมจสำเร็จรูปสำหรับ LocalStack บน Docker Hub
• เรียกใช้สคริปต์เพื่อสร้างเอนทิตีที่จำเป็นใน LocalStack เชลล์สคริปต์ใช้ AWS CLI

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

การทดสอบอัตโนมัติทำงานอย่างไร?

ในระหว่างการทดสอบ ทุกอย่างทำงานได้ใน Docker: บริการที่อยู่ระหว่างการทดสอบ, Postgres, เครื่องมือการย้ายข้อมูล และ Postman หรือเวอร์ชันคอนโซล - Newman

นักเทียบท่าแก้ปัญหาหลายประการ:

• ความเป็นอิสระจากการกำหนดค่าโฮสต์
• การติดตั้งการอ้างอิง: Docker ดาวน์โหลดอิมเมจจาก Docker Hub;
• การคืนระบบกลับสู่สถานะดั้งเดิม: เพียงแค่ถอดคอนเทนเนอร์ออก

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

การทดสอบถูกควบคุมโดยเชลล์สคริปต์ ในการทำการทดสอบบน Windows เราใช้ git-bash ดังนั้นสคริปต์เดียวก็เพียงพอสำหรับทั้ง Windows และ Linux Git และ Docker ได้รับการติดตั้งโดยนักพัฒนาทุกคนในโครงการ เมื่อติดตั้ง Git บน Windows จะมีการติดตั้ง git-bash เพื่อให้ทุกคนมีสิ่งนั้นเช่นกัน

สคริปต์ดำเนินการตามขั้นตอนต่อไปนี้:

• การสร้างอิมเมจนักเทียบท่า

  docker-compose build

• เปิดตัวฐานข้อมูลและ LocalStack

  docker-compose up -d <контейнер>

• การย้ายฐานข้อมูลและการจัดเตรียม LocalStack

  docker-compose run <контейнер>

• เปิดตัวบริการภายใต้การทดสอบ

  docker-compose up -d <сервис>

• รันการทดสอบ (นิวแมน)
• การหยุดภาชนะทั้งหมด

  docker-compose down

• การโพสต์ผลลัพธ์ใน Slack
  เรามีการสนทนาที่มีข้อความที่มีเครื่องหมายถูกสีเขียวหรือกากบาทสีแดงและลิงก์ไปยังบันทึก

อิมเมจ Docker ต่อไปนี้เกี่ยวข้องกับขั้นตอนเหล่านี้:

• บริการที่กำลังทดสอบเป็นอิมเมจเดียวกันกับที่ใช้งานจริง การกำหนดค่าสำหรับการทดสอบจะดำเนินการผ่านตัวแปรสภาพแวดล้อม
• สำหรับ Postgres, Redis และ LocalStack จะใช้อิมเมจสำเร็จรูปจาก Docker Hub นอกจากนี้ยังมีอิมเมจสำเร็จรูปสำหรับ Liquibase และ Newman เราสร้างไฟล์ของเราบนโครงกระดูกของพวกเขา โดยเพิ่มไฟล์ของเราลงไปที่นั่น
• ในการเตรียม LocalStack คุณใช้อิมเมจ AWS CLI สำเร็จรูปและสร้างอิมเมจที่มีสคริปต์ตามอิมเมจนั้น

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

ปัญหาที่คุณอาจพบ

รอความพร้อม

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

บางครั้งปัญหานี้แก้ไขได้โดยใช้สคริปต์ รอ-สำหรับ-it.shซึ่งรอโอกาสในการสร้างการเชื่อมต่อ TCP อย่างไรก็ตาม LocalStack อาจส่งข้อผิดพลาด 502 Bad Gateway นอกจากนี้ยังประกอบด้วยบริการมากมาย และหากหนึ่งในนั้นพร้อม ก็จะไม่พูดอะไรเกี่ยวกับบริการอื่น

การตัดสิน: สคริปต์การจัดเตรียม LocalStack ที่รอการตอบกลับ 200 ครั้งจากทั้ง SQS และ SNS

ความขัดแย้งของงานแบบขนาน

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

การตัดสิน: สคริปต์จะตั้งค่าตัวแปร COMPOSE_PROJECT_NAME ให้เป็นค่าที่ไม่ซ้ำ

คุณสมบัติของวินโดวส์

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

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

นี่คือวิธีการกำหนดค่า git:

git config core.autocrlf input

1. Git-bash จำลองโฟลเดอร์ Linux มาตรฐาน และเมื่อเรียกไฟล์ exe (รวมถึง docker.exe) จะแทนที่เส้นทาง Linux สัมบูรณ์ด้วยเส้นทาง Windows อย่างไรก็ตาม สิ่งนี้ไม่สมเหตุสมผลสำหรับเส้นทางที่ไม่ได้อยู่ในเครื่องท้องถิ่น (หรือเส้นทางในคอนเทนเนอร์) ลักษณะการทำงานนี้ไม่สามารถปิดใช้งานได้

การตัดสิน: เพิ่มเครื่องหมายทับเพิ่มเติมที่จุดเริ่มต้นของเส้นทาง: //bin แทน /bin Linux เข้าใจเส้นทางดังกล่าว จึงมีเครื่องหมายทับหลายอันที่เหมือนกัน แต่ git-bash ไม่รู้จักเส้นทางดังกล่าวและไม่ได้พยายามแปลงเส้นทางเหล่านั้น

บันทึกเอาท์พุท

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

วิธีแก้ปัญหาเดิมคือทำ นักเทียบท่าเขียนขึ้น ไม่มีธง -dแต่ใช้ความสามารถของเชลล์ ให้ส่งกระบวนการนี้ไปที่พื้นหลัง:

docker-compose up <service> &

วิธีนี้ใช้ได้จนกว่าจะจำเป็นต้องส่งบันทึกจาก Docker ไปยังบริการของบุคคลที่สาม นักเทียบท่าเขียนขึ้น หยุดส่งออกบันทึกไปยังคอนโซล อย่างไรก็ตามทีมงานก็ทำงาน นักเทียบท่า.

การตัดสิน:

docker attach --no-stdin ${COMPOSE_PROJECT_NAME}_<сервис>_1 &

ตัวระบุขัดแย้งกันระหว่างการทดสอบวนซ้ำ

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

เพื่อหลีกเลี่ยงปัญหานี้ ID จะต้องไม่ซ้ำกัน หรือต้องลบออบเจ็กต์ทั้งหมดที่สร้างโดยการทดสอบ วัตถุบางอย่างไม่สามารถลบได้เนื่องจากข้อกำหนด

การตัดสิน: สร้าง GUID โดยใช้สคริปต์บุรุษไปรษณีย์

var uuid = require('uuid');
var myid = uuid.v4();
pm.environment.set('myUUID', myid);

จากนั้นใช้สัญลักษณ์ในการสืบค้น {{myUUID}}ซึ่งจะถูกแทนที่ด้วยค่าของตัวแปร

การทำงานร่วมกันผ่าน LocalStack

หากบริการที่กำลังทดสอบอ่านหรือเขียนลงในคิว SQS ดังนั้นเพื่อตรวจสอบสิ่งนี้ การทดสอบเองจะต้องทำงานกับคิวนี้ด้วย

การตัดสิน: คำขอจากบุรุษไปรษณีย์ถึง LocalStack

API บริการของ AWS ได้รับการบันทึกไว้ ทำให้สามารถสืบค้นได้โดยไม่ต้องใช้ SDK

หากบริการเขียนลงในคิว เราจะอ่านและตรวจสอบเนื้อหาของข้อความ

หากบริการส่งข้อความไปยัง SNS ในขั้นตอนการจัดเตรียม LocalStack จะสร้างคิวและสมัครรับหัวข้อ SNS นี้ด้วย จากนั้นทั้งหมดก็ลงมาที่สิ่งที่อธิบายไว้ข้างต้น

หากบริการจำเป็นต้องอ่านข้อความจากคิว ในขั้นตอนการทดสอบก่อนหน้า เราจะเขียนข้อความนี้ลงในคิว

การทดสอบคำขอ HTTP ที่มาจากไมโครเซอร์วิสภายใต้การทดสอบ

บริการบางอย่างทำงานผ่าน HTTP ร่วมกับสิ่งอื่นที่ไม่ใช่ AWS และคุณสมบัติ AWS บางอย่างไม่ได้ถูกนำมาใช้ใน LocalStack

การตัดสิน: กรณีนี้ช่วยได้ MockServerซึ่งมีภาพสำเร็จรูปอยู่ ศูนย์กลางนักเทียบท่า. คำขอและการตอบกลับที่คาดหวังได้รับการกำหนดค่าโดยคำขอ HTTP API ได้รับการบันทึกไว้ ดังนั้นเราจึงส่งคำขอจากบุรุษไปรษณีย์

การทดสอบการตรวจสอบสิทธิ์และการอนุญาต OAuth

เราใช้ OAuth และ โทเค็นเว็บ JSON (JWT). การทดสอบต้องใช้ผู้ให้บริการ OAuth ที่เราเรียกใช้ในเครื่องได้

การโต้ตอบทั้งหมดระหว่างบริการและผู้ให้บริการ OAuth มาจากคำขอสองรายการ ประการแรก จะต้องขอการกำหนดค่า /.well-known/openid-configurationจากนั้นจึงขอคีย์สาธารณะ (JWKS) ตามที่อยู่จากการกำหนดค่า ทั้งหมดนี้เป็นเนื้อหาแบบคงที่

การตัดสิน: ผู้ให้บริการ OAuth ทดสอบของเราคือเซิร์ฟเวอร์เนื้อหาแบบคงที่และมีไฟล์สองไฟล์อยู่ในนั้น โทเค็นถูกสร้างขึ้นเพียงครั้งเดียวและคอมมิตกับ Git

คุณสมบัติของการทดสอบ SignalR

บุรุษไปรษณีย์ไม่ทำงานกับ websockets เครื่องมือพิเศษถูกสร้างขึ้นเพื่อทดสอบ SignalR

ไคลเอ็นต์ SignalR เป็นได้มากกว่าแค่เบราว์เซอร์ มีไลบรารีไคลเอนต์สำหรับมันภายใต้. NET Core ไคลเอ็นต์ที่เขียนด้วย .NET Core จะสร้างการเชื่อมต่อ ได้รับการตรวจสอบสิทธิ์ และรอลำดับข้อความที่ระบุ หากได้รับข้อความที่ไม่คาดคิดหรือการเชื่อมต่อขาดหาย ไคลเอนต์จะออกด้วยรหัส 1 หากได้รับข้อความที่คาดไว้ล่าสุด ไคลเอนต์จะออกด้วยรหัส 0

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

หากต้องการเรียกใช้ไคลเอนต์หลายตัวให้ใช้ตัวเลือก --มาตราส่วน บนบรรทัดคำสั่งเขียนนักเทียบท่า

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

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

HEALTHCHECK --interval=3s CMD if [ ! -e /healthcheck ]; then false; fi

ทีม นักเทียบท่าตรวจสอบ แสดงสถานะปกติ สถานะความสมบูรณ์ และรหัสทางออกของคอนเทนเนอร์

หลังจากที่ Newman เสร็จสิ้น สคริปต์จะตรวจสอบว่าคอนเทนเนอร์ทั้งหมดกับไคลเอนต์ได้สิ้นสุดลงแล้ว โดยมีโค้ด 0

ความสุขก็มีอยู่

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

การทดสอบเหล่านี้ปกป้องทีมนักพัฒนามากกว่า 30 คนจากข้อผิดพลาดในแอปพลิเคชันที่มีการโต้ตอบที่ซับซ้อนของไมโครเซอร์วิสมากกว่า 10 รายการที่มีการปรับใช้บ่อยครั้ง

ที่มา: will.com