Videos → Better testing with Vue application

เปิดงานและแนะนำตัว: คุณปุ๋ยกับเรื่องราวการ Test ใน Vue0:00

ครับ วันนี้เรียกว่าเป็นโอกาสดีที่เราได้เจอพี่ปุ๋ย ในงาน Vue นะครับผม ครับ ก็ขอมอบเวทีนี้ให้กับพี่ปุ๋ย ครับผม ครับ ขอบคุณมากครับ ครับ โอเค ขอบคุณมากครับผม

ชนก่อนนะฮะ

นะครับ โอเคนะครับเนาะ ก็เมื่อกี้แนะนำตัวไปแล้วเนาะ ดูแก่มากเลยนะฮะ โอเคนะครับ ก็ผมชื่อสมเกียรตินะฮะ นะครับ เรียกว่าปุ๋ยแล้วกันนะครับ จะมาพูดเรื่องของการ test เนาะ นะครับ การ test ตัว Vue เนาะ นะครับ ว่าเรา test ยังไงบ้าง เอ่อ ในนี้ คำถามเดิมเนาะ ใครเขียน Vue นะ สวยละ 2 เซสชั่นมานะฮะ เขียน Vue ใช่ป่ะ

ความจริงของ Dev: เสร็จแล้ว...แต่ Test ล่ะ?0:40

ใครเขียน test บ้างฮะ

สวยละ เอ้า อย่างงี้เป็น dev ทุกคนใช่ป่ะ แล้วบอกว่าเสร็จอ่ะ ทำไมบอกว่าเสร็จอ่ะ

ใช่ป่ะ เห็นนะ ทำไมบอกว่าเสร็จใช่ป่ะ โกหกชัดๆ ใช่ป่ะ นะฮะ เพราะเราต้องเสร็จก่อนเลยนะ deadline ใช่ป่ะ ถ้าไม่เสร็จโดนด่าใช่ป่ะ แต่ถ้าเสร็จแล้วมีบั๊ก ก็แก้ไงใช่ป่ะ เนี่ย เออเนาะ เออ ถูกป่ะ กล้าเจอบั๊ก กล้าแจ้ง เราก็กล้าแก้ใช่ป่ะ เนาะ ซึ่งเวลาแก้บั๊ก ไม่ตก KPI ไง ใช่ป่ะ เพราะฉะนั้นเห็นนะ ดู make sense มั้ย ไม่ make sense นะฮะ เออเนาะ แต่เป็นอย่างงี้ใช่ป่ะ

คุณภาพ vs. ปริมาณ: เลือกอะไรเมื่อ Deadline มาถึง?1:21

ความสนุกเนาะ เพราะฉะนั้นมาดูกันนะฮะ

ถามว่า Vue ผมเขียนเยอะมั้ยนะฮะ คำตอบคือไม่ค่อยเขียนนะฮะ เออเนาะ เหมือนกับ Vue Thailand News อะไรซักอย่างอ่ะ นะครับเนาะ แนะนำตัว Vue ใช่ป่ะ เขียนอะไรนะ จะ react เออ แล้วประมาณ นะ เหมือน react angular vue เราเลือกอะไรครับ react ใช่ป่ะ เออเนาะ ถูกป่ะ แต่ถ้า enterprise หน่อยจะเลือก angular ใช่ป่ะ เนาะ แต่พอมาที่นี่ต้องบอกว่า Vue โอเคนะฮะ

ดังนั้นนะฮะ ผมกำลังพูดถึงเรื่องของการ test แล้วกัน นะครับเนาะ มันเป็นเค้าเรียก rare item นะฮะ แปลว่าจะไม่มีใครทำนะครับเนาะ นะครับ ดังนั้นนะฮะ ระหว่างคำว่า quality คือคุณภาพใช่ป่ะฮะ กับ quantity คือปริมาณ เราเลือกอะไรครับ

deadline อยู่ข้างหน้าใช่ป่ะเนี่ย วันนี้มาใช่ป่ะ ต้อง deploy วันนี้มั้ย ใช่ป่ะ เออเนาะเนี่ย ต้อง deploy มั้ย ใช่ป่ะ เออเนาะ นะ

Refactor = เขียนใหม่? ความมั่นใจในการเปลี่ยนแปลงโค้ด2:24

มันจะมีอารมณ์คือนะฮะ โค้ดที่เราเขียนไปเนาะ มันดีมั้ยฮะ

ดีนะ ดู เสียงสูงเนี่ย โอเคเนาะ นะ วันดีคืนดีคือ มี lead เดินมาใช่ป่ะ ผมรู้สึกว่าโค้ดคุณไม่ค่อยดีใช่ป่ะ เรา refactor กันหน่อยมั้ย ทุกคนจะมองว่าไงฮะ refactor ใช่ป่ะ คิดในใจคือ แม่งเขียนใหม่นะฮะ refactor คือแปลเป็นไทยคืออะไรฮะ ปรับปรุงโครงสร้างให้ดีขึ้นนี่ อันนี้คือจาก basic มันเลย จาก original เลยนะ นะ แต่คำว่า refactor คือ เขียนใหม่ใช่ป่ะ โอเคป่ะ แต่ตอนที่หัวหน้าเราพูดใช่ป่ะ ไป present น่ะ ต้องบอกว่าอะไรฮะ อื้อ ใช่ป่ะ refactor ใช่มั้ย ถูกป่ะ เออเนาะ เพราะว่า refactor คุณจะทำได้ก็ต่อเมื่อคุณมั่นใจว่า สิ่งที่คุณเปลี่ยนมันยังทำงานเหมือนเดิม

เอาเหมือนเดิม ใช่ป่ะ เพิ่มเติมคือขอเปลี่ยนเวอร์ชั่นใช่ป่ะ จาก Vue เวอร์ชั่น 2 ไปเป็นเวอร์ชั่น 3 มี migration guide ให้ด้วยใช่ป่ะ migrate ได้มั้ย นี่ใช่ป่ะ เออเนาะ แต่หัวหน้าเรา migrate ได้สิ เพราะเค้ามี migration guide ใช่ป่ะ เออเนาะ จริงมั้ยไม่แน่ใจนะฮะ เออเนาะ ดังนั้นนะฮะ ตรงนี้ก็เป็นความสนุกใช่ป่ะ เออเนาะ ในของผม ผมเรียกว่าทุกครั้งที่เรา change เรามั่นใจไปว่ามันยังคงเลยฮะ โอเค มีอยู่แค่นี้ฮะ นะ ถ้าเรามั่นใจ นั่นคือความเชื่อมั่นเรา ความเชื่อมั่นเราสูงใช่ป่ะ เอาง่ายๆ ตอนเนี้ย อยากเปลี่ยนโค้ดใช่ป่ะ

ความเชื่อมั่นในการ Coding: แก้ Bug ทีเสียวทั้งองค์กร4:00

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

แล้วไม่พอเนาะ คืนนี้ยันเช้า ส่งแจ้งใช่ป่ะ พรุ่งนี้ต่อกันอีกใช่ป่ะ อยู่นานสุดกี่วันฮะ วันเดียวก็พอนะ เพราะเราไม่ไหว ต้องมีไม้สองใช่ป่ะ อะไรประมาณนั้นนะครับ ดังนั้นนะ ที่ผมพูดตรงนี้ก็คือ เรากำลังพูดถึงเรื่องอะไรฮะ ความเชื่อมั่นถูกป่ะ เพราะว่าการพัฒนา software คือการเปลี่ยนแปลงนะ มีระบบไหนมั้ยฮะ ที่เราพัฒนาแล้ว ทำแล้วทิ้ง เหมือนกระดาษทิชชู่ตรงห้องน้ำเนี่ย เออเนาะ มีมั้ย ทำแล้วทิ้ง ถ้าทำแล้วทิ้งไม่ต้องพูดถึงนะ ก็ไม่ต้อง test อะไร ถูกป่ะ ให้ user test แทนเรา โอเคมั้ยฮะ แต่เรากำลังทำ product ใช่มั้ยฮะ เราต้องเพิ่มหรือแก้ไขไปเรื่อยๆ

ระบบงานมีชีวิต: การ Test เพื่อความมั่นใจในการเปลี่ยนแปลง5:01

ยกตัวอย่างเช่น ตอนนี้ ระบบงานที่เราดูแลอยู่ฮะ วันดีคืนดี feature นี้อยากเอาทิ้งใช่ป่ะ โค้ดเราลบมั้ยฮะ comment ใช่ป่ะ ใช้ git ใช่ป่ะ add commit comment this feature ถูกป่ะ เออเนาะ

แล้วไปเขียนบนโค้ดด้วย don't delete this code เพราะว่า because in future ใช่ป่ะ

อะไรประมาณนี้ใช่ป่ะ เออ คุณๆ มั้ย ใครทำบ้างฮะ

ดังนั้นผมกำลังพูดถึงเรื่องของระดับความเชื่อมั่น ของระบบเรา หรือโค้ดเราว่า ทุกครั้งที่มี change เรามั่นใจมั้ยนะครับเนาะ ดังนั้นนะ คำถามคือเราจะทำยังไงให้มั่นใจ มันมีเยอะมากใช่ป่ะนะ ยกตัวอย่างเช่น อย่างของผมเนาะ คือการ test ใช่ป่ะนะ มันมีคำพูดนึงนะ ก็คือถ้าเราเชื่อมั่นในโค้ดเราเนาะ หรือประวัติเราดีใช่ป่ะ 2 ปีที่ผ่านมา เขียนโค้ดเอาขึ้น production ไม่เคยมี bug เลย ใช่ป่ะ เราจะทำ test มั้ย เราจะเขียน test มั้ย

อันนี้คือประวัติฮะ ถ้าประวัติดี ถูกป่ะ แต่ชีวิตจริงคืออะไรฮะ ใช่ป่ะ แค่กูหายใจใช่ป่ะ ใครเคยเจอบ้างฮะ เข้าไปบริษัทครั้งวันแรกเลย กูเพิ่งเปิดเครื่อง มี bug แจ้งมาด้วย ให้กูแก้ มีใครเคยเจอมั้ย คำถามคือ เพิ่งๆ มานั่ง ใช่ป่ะ แล้วเพิ่งๆ pull โค้ดลงมา เพิ่ง clone ลงมาเลย แล้วมึงแจ้ง bug ให้กู มึงต้องการอะไร

อันนี้เป็นเรื่องตลกที่คุยกันหน้าเซเว่นนะฮะ ตอนกินเบียร์ เขาจะพูดกันประมาณนี้นะ

สร้างความเชื่อมั่นด้วยการ Test: Manual vs. Automation6:33

ดังนั้นนะ 1 ในการสร้างความเชื่อมั่นคือ เรื่องของการ test ตอนนี้เอาเรื่องของ dev เนาะ dev คนไหนที่ test เองบ้างฮะ

ต้องยกมือทุกคนสิฮะ test เองบ้าง ถูกป่ะ เพราะว่าเรากำลังจะบอกว่า เฮ้ย งานของเราเรียบร้อย เราต้อง test เนาะ แต่เรา test แบบของเราอ่ะ บางคนบอก test แบบบ้านๆ ใช่ป่ะ สมมุติเราทดสอบอะไรฮะ สมมุติมี 3 หน้า มีคนแจ้ง bug มาว่า bug หน้า 2 เราทำไงฮะ

กู start มากดหน้า 1 แล้วให้มันเด้งมาหน้า 2 ใช่ป่ะ bug ใช่มั้ย กูแก้หน้า 2 แล้ว refresh แม่งใช่ป่ะ แล้วกด next ต่อ ผ่านปุ๊บ เสร็จแล้วครับ มีใครทำแบบนี้มั้ย ใครเค้าจะทำนะ แบบนี้ใช่ป่ะ เราเป็น professional ใช่ป่ะ programmer developer ทำมั้ยฮะ ทำ โอเคป่ะ ไม่ทำเนาะ

ดังนั้นนะครับ เรื่องของการ test ผมว่าทุกคนทำ แต่ทำ manual หรือ automation ถูกๆ มั้ยฮะ เพราะว่าอะไรฮะ ระบบงานของเรามีชีวิต feature เพิ่มเรื่อยๆ นะ แก้ feature ใหม่ของเดิม กระทบมั้ยฮะ ไม่เหลือ หรือไม่รู้ หรือก็วัดกันใช่ป่ะ

ไหว้พระก่อน Deploy: เมื่อ Environment ไม่ตรงกับ Production7:50

ดังนั้นตอนก่อน deploy เราต้องอะไรฮะ ไหว้ๆ พระใช่ป่ะ หน้าตึกนะ ตอนทำไม่ไหว้นะ แต่ก่อนจะ deploy มึงไหว้กูจัง อันนี้คือมุมมองของพระนะ เออเนาะ มึงต้องการอะไรกับกูวะ อะไรประมาณนี้ เราคงไม่ทำเนาะ ใช่ป่ะ เพราะฉะนั้นเรื่องของ test ไม่ว่า manual หรือ automation ผมไม่มีประเด็นนะ ถูกป่ะ แต่เราทำรึเปล่า แล้วเราทำซ้ำๆ อยู่ตลอดเวลามั้ยนะครับเนาะ แล้วเรามั่นใจรึเปล่านะ ดังนั้นไอ้เรื่องของพวกนี้นะ เราชอบแบบนี้มั้ย เนี่ยฮะ ใครๆ ชอบบ้างฮะ bug เนาะ

bug 1 ตัวชอบเรียก bug หลายๆ ตัวมาใช่ป่ะ อันนี้ก็จะเป็นสิ่งที่เกิดขึ้น หรือนะ เรามีหลายๆ environment ใช่ป่ะ อย่างที่บริษัทมีกี่ environment ฮะ environment คือมี dev ใช่ป่ะ มี local ใช่ป่ะ work on my machine มีอะไรอีกนะ มี test ใช่ป่ะ เพราะเห็นคุยข้างหลังมีอะไรอ่ะ บอกว่า อ๋อ ที่บริษัทเรามี QA ใช่ป่ะ เป็นเกมแล้ว ตีปิงปองใช่มั้ย กูเสร็จด้วย มึงไม่เสร็จ กูเสร็จด้วย มึงไม่เสร็จใช่มั้ย วนไปอย่างนี้นะ เออเนาะ คำถามก็คือเรามี environment ที่หลากหลายใช่ป่ะ ผ่านหมดทุก environment เนาะ ยกเว้น…?

เพราะฉะนั้นเราต้องอะไรฮะ คนจริงฮะ ต้องอะไรฮะ อ้าว ฉิบหายแล้วงานนี้นะ เออเนาะ เพราะอะไรฮะ มีที่เดียวที่บอกความจริงใช่ป่ะ เพราะที่เหลือผ่านหมดใช่มั้ย คุณๆ มั้ย มีการ sign นะ มีการเซ็น มีคนเทสต์ มีอะไร อย่างเช่นอะไรฮะ ผมไปเจอที่นึงเนาะ เค้ามี UAT ใช่มั้ย U U ย่อมาจากอะไรฮะ ใครเทสต์

อ่า user เออ ใช่ป่ะ หรือมันต้องเป็น BAT ป่ะ

business เป็นอะไรฮะ BAT แบตใช่ป่ะ หรือเป็น CAT เป็น customer ป่ะ อ่า หรือเป็น UAT คือ user สุดท้ายคือกูนี่แหละ เทสใช่ป่ะ อ่าเนาะ ดังนั้นไอ้ตรงนี้มันจะเป็นอะไรฮะ บางคนสนใจ process ใช่ป่ะ ให้ทำ แต่ชีวิตจริงคือคุณ คุณภาพใช่ป่ะ มันได้ไหมฮะ ไม่รู้ ถูกป่ะ เออเนาะ ดังนั้นไอ้ตรงนี้เป็นอะไรฮะ เป็นปัญหาเนาะ ที่ผมให้เห็นก่อนว่าในการพัฒนาซอฟต์แวร์เป็นยังไง

Test Pyramid, Test Cupcake, Test Rocket: เลือกแบบไหนดี?9:56

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

ไอศกรีมโคนใช่ป่ะ อ่า เราอยู่ตรงไหนนะ

อ่า ข้างบนนั่นแหละ ใช่ป่ะ เออเนาะ มีแบบไหนอีกนะ อ่า เดี๋ยวหลังๆ มาเริ่มเลยฮะ เฮ้ย คุณต้องเทสพีระมิดนะ พีระมิดกินไม่อร่อยใช่ป่ะ อ่า เราไม่ชอบ แต่ดีนะ สังเกตมะ หลายๆ ครั้งมีอะไรฮะ อ่า นี่เนาะ มีคัพเค้ก ที่ไหนทำคัพเค้กบ้างฮะ คัพเค้กของหวานใช่ป่ะ เป็นไงฮะ ไม่ดี ทำอะไรฮะ ทำซ้ำกับทุกที่ใช่ป่ะ เทสเราก็ไอ้ dev ก็อะไรฮะ กูเขียนเทสเว้ย กูไปเรียนมา กูทำ Test-Driven Development เว้ย ใช่ป่ะ เออเนาะ QA หรือ tester ทำ UI test เว้ย กูทดสอบด้วย manual ด้วย มี UAT อีก สังเกตไหม 3 ทีมนี้ ทดสอบเหมือนกันหมดเลยฮะ แสดงว่าอะไรฮะ 3 ชั้น ปกป้องดีป่ะ ชั้นเดียวรู้สึกเลย โดนแตกใช่ป่ะ ถูกมะ นะฮะ แต่ 2 ชั้น อื้อ ก็ยังดีใช่ป่ะ แต่คนไทยเนาะ เลขคี่กับเลขคู่ อ่ะ ใช่ป่ะ เลขคู่

รู้สึกดูแบบอะไรฮะ มันไม่ใช่ใช่ป่ะ มันไม่ถูกฮะ มันไม่ดีใช่ป่ะ ในเชิงของคนไทย ต้องอะไรฮะ เลขอะไรฮะ เลขคี่ ดังนั้นต้องเป็นเทสต้องมี 3 ชั้น นะ เออเนาะ ถูกป่ะ เออเนาะ เพื่อความปลอดภัยมันก็จะเกิดอะไรฮะ คัพเค้ก ดีไหม อื้อ ดี ขึ้นสูงด้วยใช่ป่ะ เออเนาะ นะ แล้วหลังๆ มามีอีกเนาะ ใน JavaScript มีอะไรฮะ นี่ทดสอบได้ถ้วยฮะ ทดสอบจนได้โทรฟี่ ได้โล่ โอเคป่ะ อ่า หรือบางคนบอกทดสอบจนอะไรฮะ กูเป็นจรวดแม่งเลย ใช่ไหม โอเคป่ะ เป็น rocket test แม่งเลย เออเนาะ โอเคป่ะ เออเนาะ เป็นจรวดเลย เออเนาะ เราทดสอบอันไหนฮะ อ่าเนาะ หลายๆ คนบอก

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

Regression Test: ทำไมไม่ทำ? (เพราะ Deadline)12:17

อื้อ ใช่ป่ะ เอาให้แหละ เอาให้เสร็จไปก่อน แล้วก็จะมีพี่คนนึงเดินมาเนาะ สู้ๆ เดี๋ยวพี่มีพิซซ่ากับ KFC ให้ ใช่ป่ะ

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

ทำไมตอนนั้นล่ะ ทำไมต้องทำตอนนั้น deadline deadline ใช่ป่ะ 1 คือ deadline 2 คือเพื่อนกูเสร็จแล้วใช่ป่ะ อ่า แล้วมีคนนึง มึงเสร็จแล้วใช่ป่ะ งั้นเพื่อนเสร็จเราเสร็จด้วย อ่า ใช่ป่ะ เออเนาะ ดีๆๆ โอเค deadline driven development โอเคป่ะ เออเนาะ ดังนั้น ไอ้ตรงนี้เป็นสิ่งที่เกิดขึ้น เพราะฉะนั้น นะครับ เรื่องของ effort ก็ว่ากันไปนะ

การ Test ใน Vue: Web Application และ Nuxt13:31

แต่สิ่งที่เรามาคุยวันนี้คือคุยในงาน Vue ใช่ป่ะ นะครับ เราก็ต้องมาคุยกันว่าแล้วเทสนะ สำหรับ Vue เนาะ Vue เราพัฒนาเป็นอะไรฮะ เป็น web application เนาะ ส่วนใหญ่ผมทำแบบนั้น ไม่ว่าจะเป็น Vue หรือว่าเป็น Nuxt เนาะ ผมพิมพ์ทีไรผมเป็น Next ตลอดเลยฮะ คุณๆ มะ

พิมพ์ Nuxt แล้วแม่งใน Google อ่ะ แม่งชอบอะไรฮะ Next ใช่ป่ะ เออเนาะ ใครเป็นบ้างฮะ แล้วเราก็ดูปะตั้งนานเนาะ เอ๊ะ ทำไมมันไม่เหมือนวะ นะครับ เออเนาะ ประมาณนั้นนะครับ ดังนั้น ถ้าเราต้องการเทสเนี่ย นะครับ

Test ที่ดีเป็นอย่างไร: เร็ว อิสระ รันซ้ำได้ ตรวจสอบได้ เข้าใจง่าย14:01

ในแง่ของนักพัฒนานะฮะ เทสที่ดีเป็นยังไงก่อน นะครับเนาะ มันต้องเริ่มต้นจากอะไรฮะ เขียนเทสก่อนใช่ไหม พอเขียนได้แล้วปุ๊บมันจะเริ่มเกิดว่า แล้วเทสที่ดีเป็นยังไง นะครับ 1 คือนะครับ เทสที่ดีต้องเร็ว คำถามคือเร็วขนาดไหน เร็วกว่าที่เป็นอยู่ฮะ เพราะฉะนั้นเมื่อวานเร็วอย่างไร วันนี้ต้องเร็วกว่า เค้าเรียกว่าอะไรฮะ เป็น continuous improvement นะครับ ไม่ใช่บอกว่าอะไรนะ แต่ก่อนเรารอ 3 เดือนรอได้เนาะ เดี๋ยวนี้รอ 1 ชม. รอได้ไหม ไม่ได้

อันนี้สายเสพติดความเร็วนะ เออเนาะ นะ เออ ดังนั้นนะฮะ 1 คือเร็ว 2 คือต้องเป็นอิสระ นะครับเนาะ กับอะไรฮะ สิ่งแวดล้อม นะครับเนาะ ไม่ใช่บอกว่าอะไรนะ เอ่อ เทสชุดนี้หรือโค้ดของเราอ่ะ จะรันได้เฉพาะตอนเช้า อื้อ ตอนบ่าย fail อ่า เพราะฉะนั้นเดี๋ยวรันอีกทีตอนอะไรฮะ เช้าวันพรุ่งนี้ อ่า แบบนี้คืออะไรฮะ มึงมั่วแล้วใช่ป่ะ เออเนาะ เพราะอะไรฮะ มันไม่เป็นอิสระต่อสิ่งแวดล้อมถูกป่ะ เพราะเรากำลังเทส เรากำลังสนใจอะไรฮะ feature หรือ functional เพราะฉะนั้น dependency รอบข้างต้องนิ่ง อันนี้คือวิทยาศาสตร์นะ ใครเรียนวิทยาศาสตร์บ้างฮะ นะ ฟิสิกส์ เคมี ชีวะ ต้องมีใช่ป่ะ นะฮะ วิทยาศาสตร์บอกว่าในการทดลองใช่ป่ะ คุณๆ มะ เรากำลังทดสอบเรื่องนึงใช่ป่ะ ทดลองเรื่องนึง สิ่งแวดล้อมเราต้องคุ้ม คุมได้ ถูกป่ะ อ่า กลับมาซอฟต์แวร์เนาะ อะไรคุมได้บ้าง

ตอนเราพัฒนาอะไรคุมได้บ้าง โค้ดคุมได้มั้ย

อารมณ์ตัวเองยังคุมไม่ได้ใช่ป่ะ แล้วโค้ดเมื่อกี้ 2 section มีคำว่า AI ใช่ป่ะ เดี๋ยวนี้สนุกมากเลยกับ AI ให้มัน gen ให้ใช่ป่ะ รันได้ แต่ก่อนค้นหาใน Google คลิก Stack Overflow ก็อปปี้ เราก็อปปี้คำตอบหรือคำถาม โอเคนะ ต้องถามก่อนนะ แต่ก่อนเป็นอย่างงั้นเนี่ย เดี๋ยวนี้ให้มัน gen ให้ใช่ป่ะ แล้ว gen ให้ปุ๊บมันไปเอามาจากไหนวะ แล้วพอมันได้ปุ๊บ งานเสร็จใช่ป่ะ ดังนั้นไอ้ตรงนี้ชิบหายนะ เทสต์ที่ดีคือเร็ว เป็นอิสระ

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

มรดกเลือด: เมื่อโค้ดที่เราเจอไม่ใช่โค้ดที่เราเขียน16:52

เป็นมรดกเลือดแน่นอนนะ ทุกคนจะต้องเจอใช่ป่ะ

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

Test First, Test Later, Test Last: คุณอยู่ทีมไหน?17:12

ก่อนเข้า Vue ในการเทสต์ของ Vue ปกติเราเทสต์แบบไหน มันมี test first ใช่ป่ะ คือคิดก่อนจะเขียนใช่ป่ะ กับ test later คือผมเขียน feature นี้เสร็จปุ๊บ แล้วผมค่อยเทสต์ กับอีกแบบนึงคือเขียนเยอะๆ แล้วเดี๋ยวค่อยไปเทสต์ทีเดียว ปกติเราทำแบบไหน test first test later หรือ test last

ของเราส่วนใหญ่อยู่แถวไหน บางคนบอก test later บางคนบอกว่า later เท่ากับ never ใช่ป่ะ

โครงสร้างโปรเจค Vue และ Nuxt: ง่ายต่อการ Test ไหม?17:47

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

แต่ก่อนก็ต้องเปลี่ยนว่าเดี๋ยวนี้เค้าชอบมีอะไร รันอันนี้แล้วเร็วกว่าใช่ป่ะ แต่ไม่เคยเปลี่ยนตัวเองเลย โค้ดใหญ่มากใช่ป่ะ component มีเป็นล้านใช่ป่ะ build ด้วย tool ตัวนี้ไม่ดีใช่ป่ะ เปลี่ยนไปอีก tool นึง แล้วก็เปลี่ยนไปอีก tool นึง จากเดิมเขียนด้วยอันนี้ เดี๋ยวเขียนด้วย Go Go เร็วขึ้นเว้ย สักพัก Rust มา เร็วกว่าเว้ย แล้วสิ่งที่เปลี่ยนแค่ tool ใช่ป่ะ แล้วโค้ดเปลี่ยนมั้ย ไม่เปลี่ยนนี่

ทุกอย่างเปลี่ยนยกเว้นตัวเราเอง ดังนั้นถ้าผมบอกว่าตอนนี้ผมมี 100 feature แต่ตอนนี้ผมกำลังพัฒนาอีก feature นึงใช่ป่ะ เวลา build ผมอยาก build ทั้ง 100 feature มั้ย

Feature-based Modules: ทางออกของ Build Time ที่นานเกินไป19:07

เพราะฉะนั้นมันต้องย้อนกลับมาว่า โปรเจคเรามัน build ได้เร็วและง่ายหรือเปล่า ยกตัวอย่าง อันนี้โปรเจคนึงที่ผมทำ ผมใช้ Nuxt ผมบอกว่างั้นผมแบ่งเป็น feature-based หรือว่าเป็น module นะครับ

สังเกต ผมมี main application ใช่ป่ะ main application จะมีของที่เป็น default ที่ทุกๆ แอปรันปุ๊บจะต้องมี feature เหล่านี้ เสร็จแล้วผมแบ่ง feature ออกมา อันนี้ผมเป็น domain เป็น user product catalog แต่ละทีมคนละโปรเจคเลย มี configuration มี component มีทุกอย่างแยกออกจากกัน เสร็จแล้วโอเค อยาก build ใช่มั้ย ครั้งนี้อยากได้ user add user เข้ามา

แอดอะไรฮะ แอดโปรดักต์เข้ามา แล้วคุณ build มันจะโหลดแค่อะไรฮะ สองอัน ใช่ถูกป่ะ นะซึ่งตรงนี้แหละ คำถามคือตอนที่เราทำเริ่มต้นแรกๆ ไม่ทำเนาะ เพราะมันมีอะไรฮะ feature น้อย แต่พอ feature เยอะรู้สึก build time นานขึ้นมั้ย เออ แล้วเราทำอะไร เปลี่ยน tool เปลี่ยนเครื่อง ขอเครื่องใหญ่ ใช่ป่ะ อ่านะ เห็นนะ เราจะแก้แบบนี้ใช่มั้ย แต่ถ้าผมแบ่งอันนี้ปุ๊บ ผมก็โหลดเท่าที่อะไรฮะ ผมจะใช้ แต่ถามว่ายากมั้ย โคตรยาก เพราะไม่ได้คิด โอเคป่ะ เออเนาะ นี่คือสิ่งที่เกิดขึ้นก่อนว่า ถ้าคุณจะทำเนาะ ระบบคุณต้อง testable ได้ build time คุณต้องลงมา นะครับเนาะ จากนั้นนะฮะ อันนี้คือผมให้เห็นเนาะ จากนั้นเข้าสู่การ test นี่คือหัวใจละ ประมาณ 5 นาทีนะครับ นะฮะ เราจะ test ปุ๊บ มีใครดูอันนี้บ้างฮะ นะ

เพราะเมื่อกี้ถามว่าใคร test ป่ะ ก็ไม่มีใช่ป่ะ นะหรือน้อยมากใช่มั้ย อันนี้คือเป็นอะไรฮะ best practice เนาะ แต่ผมไม่เห็นก่อนว่า ในการ test ระบบงานของเรา นะครับเนาะ อย่างแรกที่ผมจะให้ดูนะครับเนาะ ผมบอกว่าโอเค

การ Test Vue หลายระดับ: End-to-End, Isolated Test21:00

เรามี front-end อย่าง Vue เนาะ เราทำ Vue.js ถูกป่ะ แล้วต้องไปอะไรฮะ มันอยู่ด้วยตัวเองไม่ได้ใช่ป่ะ ต้องไปอะไร หลังบ้าน ถูกป่ะ อ่ะ API เนาะ อ่ะถ้า API ตายล่ะ จบ อ่า ของเราทำไงฮะ อ่ะกูนั่งรอ ใช่ป่ะ เออคงไม่ใช่เนาะ นะครับเนาะ แต่คนที่ดูแลโปรเจคอ่ะ เค้าชอบมี Gantt chart ใช่ป่ะ ของเรามีนะ ไอ้โปรเจค management อ่ะ ที่ต้องขนานกันใช่มั้ย back-end เกิดขึ้นมาหน่อย พอผ่านไปนิดนึงปุ๊บ จะต้องมีอะไรฮะ front-end ต่อ อ่า นั่นคืออะไรฮะ โปรเจค management ใช่ป่ะ อ่ะชีวิตจริง back-end ต้องเสร็จก่อน

แล้วอะไรฮะ front-end ต่อ มึง sequential เพราะฉะนั้นโปรเจคทุกโปรเจค มึงไม่เคยทัน โอเคป่ะ เออเนาะ นี่คือสิ่งที่เกิดขึ้น ทำให้ไรฮะ ท่าพิเศษต้องอะไรฮะ อยู่ OT ใช่ป่ะ เสาร์อาทิตย์ว่างมั้ยน้อง นะสักพักเดี๋ยวพี่เพิ่มคนให้ นี่ใช่ป่ะ อ่านะ มันจะมีอะไรฮะ นี่คือ 3 สเต็ปของชีวิตที่เกิดขึ้น คุ้นๆ มั้ย

แล้วก็มีคำพูดนึง สู้ๆ นะ เออเนาะ ประมาณนี้นะ ดังนั้น นะในโลกของอะไรฮะ การ test เนาะ ของ Vue ละกันนะฮะ ผมให้เห็นเนาะว่า ผมจะมีการ test หลายเลเวล อย่างแรกคือ end-to-end end-to-end คือเป็น black box นะฮะ ผมไม่สนใจว่าข้างในคุณจะเป็นยังไง แต่ผมอะไรฮะ ยิงใส่แม่งเลยใช่ป่ะ นะฮะ มีใครใช้บ้างฮะ อันนี้อ่านว่าอะไรนะ Vitest Vitest อ่ะใครใช้บ้างฮะ อ่า ใช่ป่ะ มีอะไรฮะ Cypress มี Playwright บางคนบอกเอาแก่หน่อย กู Selenium ใช่มั้ย อ่าบางคน Puppeteer ก็ว่าไป แต่นี่คือผมอยู่ข้างนอกใช่ป่ะ แล้วผมยิงเข้ามา สิ่งที่ดีคืออะไรฮะ การทำแบบเนี้ย เหมือนคนใช้งานใช่ป่ะ

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

Flaky Test: ปัญหาโลกแตกของการ Test23:06

นะครับเพราะฉะนั้น นะฮะ ในเรื่องของอะไรฮะ การ test จะเป็นลักษณะนี้ กลับอะไรฮะ เอ๊ะถ้ามันช้าใช่ป่ะ มัน flaky เยอะๆ บางคนก็แก้เนาะ มันเลยเป็นอะไรฮะ มีการ test เลเวลต่ำลงมา แต่ความเชื่อมั่นต่ำกว่า

แต่เร็วขึ้นและ repeat ได้ นะยกตัวอย่างเช่นเราชอบอะไร มี isolated test เนาะ ก็คืออะไรนะ โอเคเรากำลังทำ Vue application ใช่ป่ะ มันต้องต่อหลังบ้านเนาะ เราคุมไม่ได้ พอคุมไม่ได้ปุ๊บ กู mock แม่งเลย mock มีหลายเลเวล สมมติผมต้อง call ผ่าน HTTP protocol ใช่ป่ะ แล้ว mock ยังไง บางคนบอกกู mock แล้ว spy แม่งเลยใช่ป่ะ อ่าไม่ให้ยิงออก ถูกป่ะ อ่าคำถามคือ แล้วมึงเคยทดสอบยิงออกมั้ย ไม่เคย บางคนบอกว่างั้นกูทำ JSON ละกันนะฮะ เอา JSON ยิงถูกป่ะ อ่ะเป็นอะไร ปกติยิง HTTP protocol แต่ JSON กูอ่านไฟล์ ใช่ป่ะ แล้วแบบนี้มันจะดีมั้ย คำตอบคือไม่ดีถูกป่ะ ดังนั้นเราจำเป็นจะต้องอะไรฮะ จำลองเนาะ ให้เหมือนจริง แต่แทนที่จะไปอะไรฮะ ของจริงใช่ป่ะ แต่ให้ไปของปลอมที่คล้ายกับของจริง นะครับซึ่งตรงนี้แหละ มันก็จะมีอะไรฮะ มีเครื่องมือเนาะต่างๆ ที่โผล่เข้ามานะฮะ

Decoupling from Framework: หลีกเลี่ยงการผูกมัดกับเครื่องมือ24:19

ประเด็นคือ ผมอยากให้ดูเนาะ เวลาเหลือ 1 นาทีนะฮะ เออเนาะ เมื่อกี้บอกเนาะ ผมอยากให้ดูนะว่า Vue ที่ผมทำ ผมทำยังไงเนาะ เอาเรื่องแรกก่อน end-to-end ผม mock ใช่ป่ะ คุณๆ มั้ย ใครใช้บ้างฮะ นะครับมันมีการ mock ของจริง ถูกป่ะ แต่อะไรฮะ ไม่ยิงไปของจริง แต่ยิงมาตัวอะไร mock server นะครับเนาะ หรืออีกแบบนึง สมมติเนาะผมเริ่มต้นด้วยการเขียน อ่าอันนี้สุดท้ายเนาะ ผมเขียนปุ๊บ สังเกตนะ อันนี้ผมเขียนเริ่มต้นด้วยอะไรฮะ Playwright ใช่ป่ะ วันนี้คือดี มีดำริมาเนาะ เมื่อกี้อะไรฮะ Vitest ใช่ป่ะ อยากจะเปลี่ยนไป Vitest อ่านะ คำถามคือ

กูเปลี่ยนได้มั้ย ได้สูงด้วย แสดงว่าไม่ได้นะ เออเนาะ นะเพราะฉะนั้นนะครับ ไอ้ตรงนี้แหละ ที่เปลี่ยนยากเพราะอะไรฮะ เราผูกมัดกับเครื่องมือ กับ framework ดังนั้นอันนี้คือ make it work แต่ make it right มั้ย ไม่ เพราะฉะนั้นนะฮะ สิ่งที่เกิดขึ้นนะครับ มันมีปัญหาคือ test test ของเราผูกติดกับอะไรฮะ framework มากเกินไป ดังนั้นเราจะ decouple ยังไง นะฮะ ที่บอกว่ามันมีเคสเมื่อกี้นะ นะครับดังนั้นสิ่งที่ผมทำเนาะ 2 อันนี้นะฮะ ก่อนหน้านี้มี AI ป่ะ บางคนบอกกูเอา test case เข้าอะไรฮะ อ่าใช่ป่ะ ให้ Gen AI ใช่ป่ะ convert ให้เลย ก็ผมก็ทำมาแล้วนะฮะ 2-3 โปรเจคละ พอได้เงินนะฮะ เออเนาะ อ่านะ เออ แต่นะฮะ สุดท้ายเนาะ ผมให้ดูนะ สิ่งที่ผมทำ ผม decouple ออกมา ปกติผมทำแบบนี้เนาะ ผมทำแบบนี้นะครับ

ด้วยการอะไรฮะ ผมมี custom อะไรฮะ driver ฮะ ถูกป่ะ

พอมี custom driver ปุ๊บ ตอนที่ผมรัน ผมรันให้ดูนะฮะ นี่เนาะ ปึ๊บนะฮะ ผมลองรันเนาะ อันนี้ผมก็มึนๆ นะฮะ เออเนาะ นี่ผมรันด้วย Playwright เนี่ย โอเคป่ะ รันด้วย Playwright ปึ๊บ มันจะเปิด browser เนี่ย ปึ๊บๆ อ่าเนาะ อ่าผมบอกว่า เอ้ยผมอยากรันเหมือนเดิม แต่ผมขอเปลี่ยนเป็นอะไรฮะ ไอ้ตัว Vitest เหมือนกันนะฮะ ไม่เปิด browser นะ เพราะเมื่อกี้ตามจริงไอ้ Playwright สามารถทำเป็น headless mode ได้ถูกป่ะ อ่าส่วน Vitest ไม่ใช้ DOM โอเคป่ะ เออเนาะ ซึ่งตรงนี้ลองสังเกตเนาะ ผมสามารถอะไรฮะ เปลี่ยนได้ไปมาถูกป่ะ ซึ่งตรงนี้แหละ สิ่งที่เราต้องทำคืออะไร ตรงที่เราทำคือ custom นะผมให้ดูเนาะ สุดท้ายนะฮะ สังเกตนะผมจะมี driver เป็นอะไรฮะ Vitest กับอะไรฮะ

Playwright แล้วพอตอนผมรัน ผมเลือกว่าการรันครั้งนี้ผมจะใช้ตัวไหน ผมก็อะไรฮะ test case ผมเหมือนเดิม

Custom Driver: เปลี่ยน Test Framework ได้ง่ายๆ26:54

เพิ่มเติมคือสุดท้ายเนาะ นะฮะ สุดท้ายคือ test case เหมือนเดิม แต่เทสผม เหมือนเดิม

ตรงนี้ ตอนรัน ตอนรันผมเลือกเลยว่า ผมจะรันด้วยอะไรฮะ Vitest หรือ Playwright อ่าเนาะ โอเคป่ะ นะครับเพราะก่อนหน้านี้ Cypress มัน มี library นะครับ เพิ่มเติมเข้ามา ดังนั้นผมมีอะไรฮะ มีคนถามด้วยฮะ อ้าวแล้วนี่มึงทำยังไงวะ ก็ตอนรันกูก็แค่อะไรฮะ symbolic link เอาไง ย้าย ย้ายว่ารันครั้งนี้จะไปอะไรฮะ Playwright รันครั้งนี้จะไปอะไรฮะ Vitest นะแล้วอีกอย่างนึงผมให้ดูนะฮะ สุดท้ายเนาะ นะสุดท้ายขอเวลา 1 นาทีนะฮะ ผมลองอะไรฮะ ลองรันเนาะ server ผมลอง stop server ให้แป๊บนึงนะฮะ นะเมื่อกี้ที่กินเบียร์ผมลอง stop server start server ไว้เนาะ กลัว กลัวจำไม่ได้นะฮะ อ่าผมขอ ขอรัน Playwright ดูนะ สังเกตนะฮะ เมื่อกี้ผม stop server Playwright แม่ง fail

แล้วมันจะด่าผมนะว่า

พี่ รีวิวฮะ ก็เพราะผม stop server เมื่อกี้ใช่ป่ะ นะครับลองดูเนาะ อันนี้คือพฤติกรรมนะฮะ แต่ถ้าเป็น Vitest ผ่านเหมือนเดิมฮะ เพราะว่าอะไรฮะ

ใน driver ที่ผม create ใช่ป่ะ มัน start server เองฮะ โดยที่ไม่ต้องไป start server หลอก แล้วมันก็จะหายไปนะครับเนาะ

Test ID: ยืดหยุ่นต่อการเปลี่ยนแปลง UI/UX28:22

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

test ID เพราะว่าเราก็ทำ UI test ใช่ป่ะ สิ่งที่ดีที่สุดในการทำ UI test นะฮะ test case เราต้องไม่ผูกมัดกับ user interface นั่นหมายความว่าวันดีคืนดี UX เนาะ UI อ่ะ หน้านี้อยากเปลี่ยน แต่เจาะหน้าจอเหมือนเดิมนะ แต่ย้ายจากบนลงล่าง เทสควรต้องพังมั้ย ไม่พังสิ ใช่มั้ย

ดังนั้นเราต้องมีสิ่งนึงเนาะ อันนี้เค้าเรียกว่า test ID นะฮะ เอามาใส่เอาไว้ใน element ที่ไม่เกี่ยวกับการพัฒนานะ อันนี้คือการ decouple ออกจาก user interface ก็จะมีลักษณะนี้นะครับ นี่คือมุมมองที่ผมไม่เห็นเนาะ

Test ที่เข้าใจง่าย: Maintain ได้ ไม่เป็นมรดกเลือด29:16

และสุดท้ายนะ อันนี้ผมขอครึ่งนาทีนะ

สุดท้ายแล้ว เทสมันต้องอะไรฮะ เข้าใจได้ง่าย โอเคป่ะ พอเข้าใจง่ายๆ ปุ๊บ จากอันเนี้ย อันนี้ผมเขียนแบบง่ายๆ ใช่ป่ะ คืออะไรวะ มึงทำอะไร ถูกป่ะฮะ มันต้องอะไรฮะ เทสที่เกิดขึ้นมาต้อง maintain ได้ เพราะฉะนั้นสุดท้ายเนาะ เทสต้องเข้าใจใช่ป่ะ ดังนั้นผมเปลี่ยนใหม่ด้วยการอะไรฮะ แบบนี้เข้าใจง่ายขึ้นมั้ย ถูกป่ะ เป็น level นะฮะ make it work ก่อน แล้ว make it right ถูกป่ะ แล้วจากนั้นปุ๊บเราหาวิธี make it fast แต่ส่วนใหญ่เราชอบทำอะไรฮะ make it work make it work make it work make it work แล้วสุดท้ายเดี๋ยวมีคนเดินมาอยากให้เร็ว มันเป็นไปไม่ได้

Make it Work, Make it Right, Make it Fast: อย่าหยุดแค่ Make it Work30:01

โอเคมั้ย ดังนั้นนี่คือจุดนึงเนาะ ที่ผมอยากให้เห็นก่อนว่าใน Vue เนี่ย เราสามารถทดสอบลักษณะนี้ได้ ตามจริงสิ่งที่ผมใช้เนาะ library ที่ผมใช้

นะครับเมื่อกี้เนาะ ผมใช้ Vitest ใช่ป่ะ สังเกตมั้ย ได้เปิดหน้าจอใช่ป่ะ ผมใช้ควบคู่กับอะไรฮะ test framework library ตรงนี้ แต่สุดท้ายเนาะ ถ้าคุณไปอ่านใน Vue นะฮะ ใน Vue บอกว่าอย่ามาใช้นี้นะ เพราะอะไรฮะ มันจะมีปัญหากับ component ที่โหลดมาเป็น asynchronous เค้าให้ไปใช้อะไรฮะ ไอ้ตัว test util แทนนะ แต่ในงานของผมเนาะ ผมยังใช้ได้นะครับเนาะ

คุณภาพ vs. ปริมาณ: คุณเลือกอะไร?30:38

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

มีมั้ยฮะ เค้ารีบนะ วันนี้ผมรีบนะ โอเคป่ะ นะฮะ มีมั้ยฮะ อันเนี้ย ต้องมีคำถามป่ะ หรือเกินมานานละ โอเคนะฮะ โอเคเนาะ เพราะฉะนั้นขอบคุณทุกคนครับผม

โทษทีนะฮะ เกินไปนิดนึงฮะ เออเนาะ โอ้โห นะ