Відео

แล้วถ้าให้​ AI เขียนให้แล้วมันจะเป็น​ challenge ตรงไหนหรอครับ​ เขาตั้งโจทย์​มาให้แก้ปัญหาด้วยมนุษย์​ไม่ใช่​ AI ครับ​

@@008นนทกร ก็แก้ปัญหาด้วย AI สิครับ AI มันก็คือการเขียนโปรแกรม อีกแบบหนึ่ง ต่างอะไร จาก มนุษย์เขียนล่ะครับ ตามโลกให้ทันด้วย นะ คิดว่าใช้ AI ช่วยแล้วจะแก้ ปัญหาได้ไหม ด้วยนะ ไม่ใช้ รู้จักแต่ชื่อ AI แต่ใช้ไม่เป็นก็เป็น ง่อย เหมือนเดิมนะ

ขอบคุณสำหรับคำถามครับบ 1. ใช่ครับ เมื่อเราสร้าง API หรือ feature ใดๆ ขึ้นมา หากต้องการให้มีเส้นทางสำหรับ scenario test เราก็ต้องเพิ่มโค้ดเพื่อรองรับส่วนนี้เพิ่มเติมครับ ผมมองว่า developer และ tester ก็เป็น user ของแอปเหมือนกัน ดังนั้นระบบควรมีวิธีให้ผู้ที่เกี่ยวข้องสามารถตรวจสอบความถูกต้องของการทำงานได้ โดยไม่ต้องเข้าไปดู implementation details ข้างในเอง หากมีสิทธิ์ก็ควรจะสามารถตรวจสอบได้เลย ตอนออกแบบก็จะพยายามคำนึงถึง developer และ tester เพื่อให้มี tools สำหรับทั้งสองกลุ่มนี้ในการใช้งานและตรวจสอบระบบครับ 2. สำหรับ Trigger API เราไม่ได้ออกแบบไว้ตั้งแต่แรกครับ แต่เราได้ไอเดียมาจากการที่เราต้อง implement test สำหรับเคสที่มีเหตุการณ์เฉพาะเจาะจงเกิดขึ้น (อย่างเช่นการจองที่นั่งชนกัน) เราจึงรอให้เจอ event นั้นๆ ก่อน แล้วค่อยมาออกแบบว่าจะให้มันทำงานอย่างไรครับ จากที่เล่าในคลิป (ประมาณนาทีที่ 25) ตอนแรกเราเคยลองทำเป็น API สำหรับสร้างของแต่ละชนิด แต่ก็พบปัญหาต่างๆ เลยรื้อมาทำเป็น Scenario+Trigger API แทนครับ ซึ่งตัว framework ไม่ได้ provide สิ่งนี้มาให้ เราต้องสร้างขึ้นมากันเองครับ เทคนิคพวกนี้คือเกิดจากการลองผิดลองถูกมาสองสามรอบครับบ

@@dtinth รบกวนถามเพิ่มเติมสมมติว่า ใน scenario นั้นต้องมี user ซึ่งเราใช้ user จาก 3rd party อย่างนี้เราจะกำหนดยังไงอ่ะครับ ? เช่น สมมติเราใช้ supabase แล้วเราต้องเรียกพวก user หรือข้อมูลคต่างๆจาก library อ่ะครับ จังหวะทำ scenario เราจะแบบสมมติมันขึ้นเหมือนเหมือนทำพวก unit test ไหมอ่ะครับ ?

@@KarunJaraslertsuwan อันนี้ขึ้นอยู่กับว่าเรามองว่าข้อมูลนั้นอยู่ในระบบเราไหมครับ เช่น ・ แบบที่ 1 - แอพใช้ Supabase เก็บ user แต่ DB ของ Supabase ไม่ได้แชร์กับแอปอื่น - เราอาจจะมองว่า Supabase เป็นส่วนนึงของ app เราด้วย ดังนั้นก็อาจจะทำให้ตอน set up scenario ไปสมัคร user ใน Supabase ใหม่ให้ด้วย (e.g. โดยใช้ Supabase Auth Admin) ・ แบบที่ 2 - Supabase มองเป็น 3rd party ไม่ถือเป็นส่วนหนึ่งของแอพ - เคสนี้ปกติผมจะสร้าง test double ขึ้นมาครับ แต่กรณีของ Supabase ก็อาจจะง่ายกว่าหน่อย เพราะเราสามารถเอา Supabase มารันบน local environment ระหว่าง test ได้ เหลือแค่ชี้ให้แอพไปคุยกับ Supabase ตัว test instance แทน แล้วก็เขียน test script ให้ใช้ Auth Admin API เพื่อสร้าง user ในฝั่ง Supabase ก่อนที่จะมาสร้าง scenario ภายในระบบครับ

@@dtinth อยากให้มี vdo สอนเกี่ยวการ set up เป็นแบบ curd project เล็กๆ พอเป็นไปได้ไหมครับ พอดีลองฟังแล้วเข้าใจ concept แต่ตอนจะ implement มันเหมือนไม่รู้จะไปเริ่มอะไรยังไงดี แบบตอนแรกไม่มี scenario api เราเขียน test ตั้งแต่ unit, integration ก่อนไหมครับ แล้วค่อยไปเริ่ม test ตัวนี้

ตอนนี้ยังไม่มีครับ แต่ถ้ามีเมื่อไหร่เดี๋ยวไว้จะมาอัพเดตนะครับบ (แต่น่าจะยังไม่ใช่เร็วๆ นี้ ;-;) แต่เบื้องต้น คิดว่าเริ่มจากทำ API ง่ายๆ ของแต่ละ scenario ก่อนได้ครับ เช่น POST /api/tester/scenarios/FooScenario POST /api/tester/scenarios/BarScenario พอจำนวน scenario เริ่มเยอะขึ้น ก็จะเริ่มเห็นโค้ดที่มันซ้ำๆ กัน ซึ่งโค้ดพวกนี้เราสามารถแยกออกมาเป็น utility module ได้ครับ แล้วหลังจากนั้นก็จะเริ่มเห็นว่ามันมีโค้ดที่เป็น boilerplate เยอะขึ้น ซึ่งถึงจุดนั้นก็อาจจะแยกออกมาเป็นสร้างเป็น library หรือ internal framework ต่อได้ครับ (ซึ่งตรงจุดนี้ท่าที่ทำได้จะขึ้นอยู่กับภาษาและ base framework ที่ใช้ครับ)

ขอบคุณสำหรับคำถามครับ - ตอนที่เรียก scenario setup API เราจะสร้าง trigger ไว้ในระบบครับ (ก็คือเก็บเป็น row ใน database ไว้เลย) ว่าให้ trigger id นี้ให้ทำอะไรบ้าง ตัวอย่างเช่น { id: 234, action: "mark_seat_as_sold", parameters: { seat_ids: [789] } } ทีนี้ตอนเราไปเรียก `POST /api/tester/triggers/789` ตัว endpoint มันจะไปโหลด row นั้นออกมาจาก database แล้วดำเนินการตาม action และ parameters ที่กำหนดไว้เลยครับ แปลว่าทุกครั้งที่เรา setup scenario ก็จะได้ trigger id ใหม่ ที่สัมพันธ์กับ scenario นั้นๆ ที่ถูกสร้างขึ้นมาครับ

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

ขอบคุณสำหรับคำถามเพิ่มเติมครับ ・ เรื่องการชนกันของการจองที่นั่ง - เราออกแบบ scenario ไว้สำหรับแต่ละ test case โดยเฉพาะครับ เช่น OrderSeatingScenario เราจะ fix ข้อมูลทั้งหมดไว้เลยว่าจะมีกี่โซน กี่ที่นั่ง มีบัตรกี่รูปแบบ รวมถึงที่นั่งไหนจะถูกซื้อตัดหน้าเมื่อเรียกใช้งานตัว trigger (ซึ่งในเคสนี้ เรา hardcode ไว้ว่า ที่นั่งแรกสุดของโซนแรกสุดจะถูกซื้อตัดหน้า) ทำให้โค้ดฝั่ง test สามารถเลือกที่นั่งนั้นได้เลย โดยไม่ต้องใช้ API อื่นเพื่อดูว่าจะจองที่นั่งไหนให้ชนกัน เพราะมันถูกกำหนดไว้แล้วในตัว scenario ครับ ・ เรื่องการใช้งาน scenario API ใน CI/CD - scenario API ไม่ได้มีไว้แค่สำหรับ tester ที่ขี้เกียจจิ้มหน้าจอ แต่เราใช้ใน CI/CD ด้วยครับ คือการสร้าง event ผ่าน UI ทุกครั้งในแต่ละ test case จะใช้เวลานานมากใน CI/CD เราจึงใช้ Scenario API เพื่อสร้างสถานการณ์ที่ต้องการได้รวดเร็ว โดยถึงแม้ scenario API จะข้ามขั้นตอนการสร้าง event ผ่าน UI ไป แต่เราก็มี test อื่นๆ ที่ครอบคลุมขั้นตอนการสร้าง event ผ่าน UI จริงๆ ด้วย เพื่อให้มั่นใจว่าทุกอย่างทำงานถูกต้องครับ

ถามอีกนิดคับ test script ui ที่กำลังเขียน มันใช่ event 664 เหมือน ที่มันเกิด ตอนเราไปเอา trigger มาหรือปล่าว 234 มันทำหน้าที่ เลือกที่นั่ง ของ event 664 ใช่มั้ยคับ ถ้าใช่ ที่นั่งมันไม่ได้ โดนเลือก ตอนเรารัน scenario API แล้วหรือคับ

​@@nutttytube ใช่ครับ trigger 234 ทำหน้าที่เลือกที่นั่ง ของ event 664 - แต่ทุกครั้งที่รัน test script ตัว script มันจะไปยิง scenario API ใหม่ตลอดครับ หมายความว่า ทุกครั้งท่ีรันเทสต์ ระบบจะสร้าง event ใหม่ พร้อมกับ trigger ใหม่ ให้สำหรับการรันเทสต์ครั้งนั้นโดยเฉพาะครับ (ตัวอย่างเช่น ก็จะได้ trigger 240 เลือกที่นั่งของ event 665)

ไม่ได้ใช้ gem อะไรเป็นพิเศษครับ อันนี้เราเขียนใช้กันเองครับบ

ใช้อยู่ครับบ เวลา ssh หรือเวลาใช้งานบนมือถือ ใช้ Vim เป็น ช่วยได้มากฮะ Advent of Code ปีนี้ หลังๆ ผมลองกลับมาเล่นผ่าน Vim (kickstart.nvim) และ Zellij ครับ - Kickstart.nvim - ua-cam.com/video/m8C0Cq9Uv9o/v-deo.html - Zellij - manual.omakub.org/1/read/15/terminal ผมเคยทำคลิปเทียบ VScode กับ Vim อยู่ (ภาษาอังกฤษ) แต่โดยรวม คิดว่าถ้าศึกษาแล้วมันใช้สะดวกทั้งคู่ ลองดูได้ครับ ua-cam.com/video/8EKK7b5h7XE/v-deo.html

พี่ครับ ถ้าจะเริ่ม เขียนโปรแกรม เริ่มจาก ภาษาไหนดี อ่ะ

มี keyword ในการเรียนเรื่องพวกนี้ไหมครับ

Keywords: - Browser automation - Automated testing - Web scraping - Playwright - Puppeteer - Selenium - Cypress

น่าจะพื้นฐานการทำบอทกดซื้อของ กดจองตั๋วคอนเสิร์ตมากกว่าฮะ 😅

ใช่เลยแหละ

@@unteejo3678 ขอบคุณมากครับผม

มีตัวช่วยอยู่ครับ เช่น Playwright เป็นต้น หลักๆ ก็กด F12 ใน Chrome เพื่อส่องโค้ด HTML คร่าวๆ ด้วยตนเองก่อน แล้วลองดูว่าจะใช้ Playwright มาช่วยอย่างไรได้บ้าง ประมาณนี้ฮะ