• กระบวนการคิดเพื่อเตรียมทำ Automated Test
• Unit Test
• Integration Test
• DI (Dependency Injection)
• Stub (Test Double)
• Code Coverage

ระบบที่จะทำในบล็อกนี้

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

• สามารถแลกเงินได้ตั้งแต่ 1$ ขึ้นไป
• ต้องแลกเป็นเงินจำนวนเต็ม 1$ เท่านั้น ไม่สามารถแลกเงินเป็นเศษได้
• บวกค่าธรรมเนียมการแลกเงิน 2.50% จากราคาปกติ เมื่อลูกค้าแลกเงินในช่วง 1$ – 100$
• บวกค่าธรรมเนียมการแลกเงิน 2.15% จากราคาปกติ เมื่อลูกค้าแลกเงินในช่วง 101$-500$
• บวกค่าธรรมเนียมการแลกเงิน 2.00% จากราคาปกติ เมื่อลูกค้าแลกเงินตั้งแต่ 501$ ขึ้นไป
• แสดงค่าอัตราแลกเปลี่ยนเป็นทศนิยม 2 ตำแหน่ง ถ้ามีเศษให้ปัดขึ้นเสมอ โดยพิจารณาที่ตำแหน่งที่ 2 (ตัวอย่าง 1 USD = 35.00THB + 2.5% = 35.875THB = 35.88THB)
• ให้ดึงค่าอัตราแลกเปลี่ยนจาก BOT API ที่ https://iapi.bot.or.th/Developer?lang=th (ใช้ API: อัตราแลกเปลี่ยนเฉลี่ย – รายวัน)

ตัวอย่างของโจทย์นี้คือ … ผมเป็นบริษัทรับแลกเงิน จะคำนวณเงินบาท (THB) ที่ลูกค้าต้องจ่าย เพื่อแลกกับจำนวนเงินดอลลาร์ (USD) ที่ต้องการ เช่น ลูกค้าต้องการเงินจำนวน 1$ เมื่อดึงข้อมูลจากธนาคารแห่งประเทศไทยได้ 35 บาท ผมจึงบวกค่าธรรมเนียมอีก 2.5% และปัดเศษขึ้นกลมๆ แปลว่าลูกค้าต้องจ่ายให้ผม 35.88 บาท

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

จะทำ Automated Test ต้องเริ่มต้นที่ออกแบบ

จากโจทย์ ผมกำหนด Input, Output ง่ายๆ ให้ระบบผมก่อน ในที่นี่ Ouput คือ “เงินบาทที่ลูกค้าต้องจ่าย” ส่วน Input ผมใส่ “จำนวนเงินดอลลาร์ที่ลูกค้าต้องการ” และผมขอเพิ่ม “วันที่อ้างอิงของอัตราแลกเปลี่ยน” ที่ผมต้องการด้วย เพื่อกำหนดค่าของวันให้คงที่ ใช้ในกรณีผมต้องการทดสอบ (และเผื่ออนาคตถ้าผมอยากเปลี่ยน Business Condition ทางวันที่)

จาก Process กล่องดำๆ มืดมัว (Black Box) ผมจะแจกแจงเพื่อให้เข้าใจกระบวนการทำงานของมันเสียก่อน (White Box) ซึ่งผมถนัดคิดออกมาเป็นข้อๆก่อน จึงขอร่างไว้ดังนี้

วันก่อน มีน้องในทีมถามว่า “ผมจะเขียน Integration Test อย่างไรดี” ก็เลยได้ย้อนไปทบทวนประสบการณ์ หาข้อมูล และถามจากผู้รู้เพิ่มเติม จึงกลับไปเล่าให้น้องฟัง ก็คิดว่ามีประโยชน์ จึงอยากแชร์ไว้มาแลกเปลี่ยนความรู้กัน

ต้องเข้าใจโครงสร้างโปรเจ็คเสียก่อน

ทุกวันนี้เราเข้าใจโครงสร้างของโปรเจ็คเราดีแล้วหรือยัง หรือถ้าเข้าใจดีแล้ว เราได้แยกส่วนชัดเจนไหมว่าส่วนไหนเป็นโค้ดของระบบ (Production Code) และส่วนไหนเป็นโค้ดของการทดสอบ (Test Code)

ขอยกตัวอย่าง ถ้าผมจะเขียนโปรเจ็คตัวหนึ่งคือ ระบบ API (My API) โดยมีการเชื่อมต่อไปยังระบบ API ข้างนอก (External API) จากนั้นผมมีโปรเจ็ค Test แยกออกมาอีกตัวหนึ่ง รูปร่างหน้าตามันก็จะเป็นเช่นนี้

(รูปโครงสร้างโปรเจ็ค)

ลองเจาะลึกเข้าไปในการทำงานของโปรเจ็ค ในที่นี้ผมเขียนเป็น MVC ซึ่งถ้าผมเป็น User ผมจะเรียกใช้ API ตัวหนึ่ง ผ่าน Controller จากนั้นไปเรียก Services เพื่อทำการติดต่อไปยัง External API และรับค่ามาแสดงให้ User ได้เห็น

(รูปการทดงานภายในโปรเจ็ค)

แยกโปรเจ็คของชุดทดสอบ (Test) ให้ชัดเจน

จากรูปการทดงานภายในโปรเจ็ค, ผมสมมติว่า Controller ผมมี Business Logic อะไร เป็นเพียงการรับ Request และส่งผ่าน Data ไปให้ Services ทำงานต่อ คราวนี้ถ้าผมจะเขียนทดสอบ ผมควรต้องเขียนทดสอบที่ Services ซึ่งในที่นี้ผมจะทดสอบการทำงานในชั้นที่เล็กที่สุด นั่นคือ Unit Test

แต่ตามทฤษฎีแล้ว คุณสมบัติที่ดีของ Unit Test จะต้องเป็นไปตามหลักการของ FIRST คือ

• Fast: ทำงานได้เร็ว
• Isolated: เป็นอิสระจากกัน
• Repeatable: ทำซ้ำได้ ไม่ขึ้นกับระบบอื่นๆ เช่น API ภายนอก, Database, File System
• Self-Verify: แสดงให้เห็นผลการทดสอบ ผ่าน หรือไม่ผ่านได้อย่างชัดเจน
• Timely: เขียนให้ถูกเวลา คือ ควรมี Test ก่อน เพื่อให้ได้เข้าใจปัญหา และจึงเขียนโค้ดเข้ามาแก้ปัญหานั้น

หมายความว่า ถ้าผมทำ Unit Test ผมจะไม่สามารถทำการทดสอบได้เลย ถ้า External API พัง หรือ Internet ล่ม เป็นต้น

ดังนั้น ผมต้องเขียนโค้ดทดสอบเพิ่มเข้ามาอีกชุด  ที่เรียกว่า Integration Test

(รูปการทำงานภายในโปรเจ็คที่มี Unit Test และ Integration Test)

ถ้าดูจากเส้นการทำงาน ผมจะเขียน Unit Test เพื่อทดสอบแค่กระบวนการภายใน Services ของผมเอง (เส้นสีน้ำเงิน) ส่วน Integration Test ผมจะทดสอบกระบวนการที่ Services ผมไปเรียกใช้ External API (เส้นสีเขียว)

วิเคราะห์การทำงานของโค้ด และแยกแยะให้ถูก

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

ผมสมมติว่า Services ที่ผมทำขึ้นมี Method ชื่อว่า IsAdd() โดยรับหมายเลขสองตัวมาบวกกัน จากนั้นส่งไปให้ External API ตรวจสอบว่าคำนวณถูกต้องไหม ถ้าถูก ให้คืนค่า True กลับมา

(รูปของ Method IsAdd() ที่ยังไม่รู้กระบวนการภายใน)

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

(รูปของ Method IsAdd() ที่เราวิเคราะห์ว่ามีการทำงานใดเกิดขึ้นบ้าง)

หลังจากวิเคราะห์ออกมา เราพบว่ามีการทำงานสองส่วนคือ

• Process A: เป็นการคำนวณเลขสองตัวที่รับเข้ามาว่าบวกกันได้เท่าไร
• Process B: นำค่าที่ได้จากการคำนวณ Process A ส่งไปให้ External API และรับค่าผลลัพธ์กลับมา

แปลว่า เราต้องแบ่ง Method ตัวนี้ออกเป็นสอง Method เพื่อทำการทดสอบ Unit Test กับ Process A และ Integration Test กับ Process B

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

(รูปของ Method IsAdd() ที่เราวิเคราะห์การทำงาน และแบ่งชุดทดสอบ)

ต้องรองรับกระบวนการ Continuous Integration ได้ด้วย

เมื่อโครงสร้างของโปรเจ็คและโครงสร้างของโค้ดเรา สามารถรองรับการทดสอบได้แล้ว สิ่งที่ต้องคิดต่อมาคือ จะนำเข้ากระบวนการ Continuous Integration ได้อย่างไร เพื่อให้เกิด Pipeline และ Feedback Loop ที่เร็ว

เพราะ Unit Test สามารถอยู่ได้ด้วยตัวเอง แต่ Integration Test จะต้องเกี่ยวข้องกับระบบอื่นๆ เช่น  Database หรือ File System ซึ่งระบบเหล่านี้ควรมีประบวนการพร้อมใช้งานก่อน ดังนั้น ถ้ามันอยู่ร่วมโปรเจ็คเดียวกัน คงไม่ดีแน่นอน และไม่รู้ได้ด้วยว่าถ้าเกิดการรันและ Fail มันเกิดที่กระบวนการของ Unit หรือ Integration กันแน่ จึงควรแยกโปรเจ็คของชุดทดสอบนี้ออกจากกัน

(รูปของ Method IsAdd() ที่เราแบ่งชุดทดสอบ ออกเป็น 2 Project)

(รูปตัวอย่างเมื่อแยกโปรเจ็ค Unit Test, Integration Test แล้ว สามารถกำหนด Pipeline ให้เหมาะสมได้)

Tip: ใช้ Postman ทดสอบ Integration Test จะได้หรือไม่

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

คำตอบคือ ใช้ Postman ทดสอบเรียก API จะไม่เรียกเป็น Integration Test แม้ว่าภายใน API นั้นจะเรียกไปที่ต่างๆจริง คืนค่าจริงกลับมา, แต่ถ้าให้ถูกต้องจะเรียกว่า End-to-End Testing

เพราะเราเอาระบบภายนอก (Postman) เรียกไปที่ API ว่าทำงานได้หรือไม่ แต่เราไม่ได้ทดสอบว่าระบบทั้งสองทำงานถึงกันได้หรือไม่ (เส้นสีชมพู) นั่นจึงเป็นที่มาว่า ใช้ Postman ก็อาจไม่ชัวร์ว่า ระบบเราจะทำงานได้จริง

หรือให้ลองนึกอีกที เคยไหมครับ ที่ใช้ Postman ทดสอบ API ได้ แต่พอรันโค้ด กลับทำงานไม่ได้ เพราะมี คอมพิวเตอร์เรามี Environment เรียกใช้ต่างกันกับเครื่อง Server เป็นต้น

Tip: ถ้าอยากทดสอบทุกกระบวนการ แต่ไม่ต่อไปถึง External API จะทำอย่างไร

เป็นคำถามที่ถูกถามบ่อยเหมือนกัน และโปรแกรมเมอร์ก็มักเจอบ่อยเช่นกันว่า

• ถ้าจะทดสอบ Services ตัวเอง โดยยังไม่อยากไปเชื่อมต่อระบบภายนอก
• อยากทดสอบ Services ตัวเอง แต่ระบบภายนอกยังทำไม่เสร็จ
• อยากทดสอบ Services ตัวเอง แต่ระบบภายนอกทำงานช้า ไม่ทันใจ

จากปัญหาข้างต้น เราสามารถนำวิธีการชื่อว่า Stub จาก Test Double มาใช้ได้ คือทำ Stub ตัว External API มันซะเลย เพื่อให้ได้ค่าที่เราต้องการเสมอ และไม่ต้องออกไปรับค่าจริงจาก External API

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

เราจะเรียกการทดสอบแบบนี้ว่า Component Test ซึ่งในที่นี้เราต้องการทดสอบการทำงานทั้งหมดของ Service เรา แต่เราไม่ได้สนใจว่า External API จะอยู่หรือจะตาย ทำงานได้ถูกต้องหรือไม่ ดังนั้น เราจึงต้องจำลอง External API มันขึ้นมา โดยใช้ Stub นั่นเอง (เขียนเองก็ได้ หรือหา Library ฟรีมาใช้ก็ได้ เช่น  .Net Core: Stuberry, Java: Stubby4j)

สรุป

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

สำหรับตัวอย่างการแยก Test ลองดูที่ GitHub ของผมได้ครับ มีแต่ .NET Core นะ กำลังอิน ฮ่าๆ (BOT UnitTest, BOT IntegrationTest, BOT Service)

อ่านภาคการนำไปประยุกต์ใช้ต่อได้ที่ ภาคปฎิบัติ: จะทำระบบให้รองรับ Automated Test ได้อย่างไร (Testable)

จัดการสิทธิเพื่อใช้ Deployment

ขั้นตอนนี้จะให้นำ SSH Key ของ Jenkins ไปทำความรู้จักกับ Bitbucket
ก่อนอื่น ทำการตรวจสอบก่อนเลยว่า user jenkins ใน server เรา เชื่อมต่อ bitbucke.org ได้ไหม ด้วยคำสั่ง

[wc_code]$ sudo -u jenkins ssh -vT git@bitbucket.com[/wc_code]

ให้ดูบรรทัดท้ายๆ ถ้ามันมี username ที่เราใช้บน Bitbucket แปลว่ามันรู้จักกันแล้ว

แต่ถ้าขึ้นว่า Permission Denied  ให้ทำการ copy public key ไปไว้บน bitbucket ครับ โดยวิธีการดู Jenkins public key คือ

[wc_code]$ sudo vi /var/lib/jenkins/.ssh/id_rsa.pub[/wc_code]

เป็นอันเสร็จเรียบร้อย

สร้างโฟลเดอร์เว็บไซต์ และไฟล์คำสั่ง Deployment

ไฟล์เว็บไซต์ผมจะเก็บไว้ที่ /var/www/test_ci_cd และเมื่อมีโฟลเดอร์แล้ว ให้ clone project ลงมาทั้งหมด

[wc_code]$ sudo mkdir /var/www/test_ci_cd[/wc_code]

[wc_code]$ sudo git clone git@bitbucket.org:few/test-project.git .[/wc_code]

ทำการสร้างไฟล์เพื่อใช้ Deployment ซึ่งในที่นี้ผมใช้ชื่อ deploy.php

[wc_code]$ sudo vi /var/www/test_ci_cd/deploy.php[/wc_code]

ในไฟล์มีโค้ดประมาณนี้

ซึ่งเป็นโค้ดที่ Jenkins จะเอาไว้ใช้งาน โดยมีขั้นตอนคือ

1. เข้าโฟลเดอร์ที่เก็บเว็บไซต์ (หรือเก็บไฟล์ deploy.php)
2. ทำการล้างไฟล์เก่าออกทั้งหมด (optional)
3. ดึงไฟล์ล่าสุดที่มีการเปลียนแปลงและผ่านการทำสอบแล้ว ลงมาบน server

จากนั้นทำการบันทึก ก็เสร็จแล้ว

เพิ่ม Config Deployment บน Jenkins

เข้าไปที่ Project ที่เราใช้ทำงาน จากนั้นเพิ่มในส่วนของ Build จุดเดียวกับที่ตั้งให้ทำ PHPUnit ดังนี้

ซึ่ง folder path และชื่อไฟล์ ให้เปลี่ยนไปตามที่เราตั้งค่าไว้ด้วยนะ

ลองทดสอบ Automation Deployment

ตอนนี้ไฟล์ที่ผมใช้ทดสอบทำงานบวกเลขได้ตามปกติ และไฟล์ test unit ผมก็ยังใช้งานได้ตามปกติ
ผมจะลองเพิ่มข้อความบนไฟล์ calculate.php โดยยังไม่ได้แก้ไขอะไร เพื่อดูว่าระบบไหลไปได้ถูกต้องหรือไม่

[wc_code]echo ‘Hi, automate test and deploy (success, all test case)’;[/wc_code]

จากนั้นให้ Push เข้าสู่ระบบ

ลองเปิดดูบน Jenkins จะต้องพบว่ามัน Success

จากนั้นลองเปิดบนเว็บไซต์ Production ที่เราได้เตรียมไว้ จะต้องแสดงข้อความที่เพิ่มขึ้นมา

แปลว่า ระบบ Jenkins ทำการทำการ Automate Test และเมื่อทดสอบ Unit Test ผ่านทั้งหมด ก็ได้ Automate Deploy ให้เราเรียบร้อยแล้ววว

คราวนี้ มาลองทดสอบกรณีที่ Unit Test ทำงานไม่ผ่านบ้าง
โดยผมได้แก้สูตรคิดเลข จาก บวก เป็น หาร ดังนั้น Unit Test ที่ผมทำการทดสอบไว้ทั้งหมดจะผิดทันที เพราะคำตอบมันเป็นผลลัพธ์ของการบวกเท่านั้น
และผมได้ทำการแก้ไขข้อความด้วยว่า จะเกิดการ fail, all test case

เช่นเดิม แก้ไขเสร็จ ทำการ git push ขึ้นไปบน Bitbucket

จากนั้นเมื่อไปดูบน Jenkins มันจะแสดงข้อความ FAILURES ขึ้นมา เพราะ Unit Test เราไม่ผ่าน

ดังนั้น ไฟล์บน Procution ก็จะไม่มีอะไรเปลี่ยนแปลง เพราะเมื่อ Unit Test ไม่ผ่าน มันจะไม่ไปเรียกไฟล์ deployment ทำต่อ

สรุป

จากที่ได้ลองผิดลองถูกทำมาจนครบ ทำให้เห็นภาพได้ชัดเจนเลยครับว่า Continuous Integration และ Continuous Deployment มันสะดวกและเร็วขึ้นมาก ช่วยส่งเสริมกับเรื่องการส่งมอบงานเป็นรอบและส่งให้ได้ไว เพื่อให้มีการ feedback เร็ว ดังนั้น การเสียเวลาศึกษาและตั้งระบบขึ้นมาอีกสักหน่อย มันจะช่วยงานเราได้ในระยะยาว

แต่อย่างที่ชื่อเรื่องบอกนะครับ นี่เป็นเพียงการเริ่มต้น ดังนั้นขั้นตอนที่เราจะใช้งานจริงๆ อาจจะมีมากกว่านี้ที่ต้องเพิ่มขึ้น ทั้งการเพิ่ม Security, การเพิ่มเรื่องของ Test, การ git push ไปพักไว้ที่ dev branch ก่อน, การ Deploy ไปยัง Stating Server เพื่อทำ Acceptant Test แล้วค่อย merge git เข้าสู่ master branch และ deploy Production … ผมก็คงเขียนไม่หมด เอาเป็นว่า ไปเผชิญโลกกว้างกันดูครับ

(รูปจาก http://www.bogotobogo.com/DevOps/DevOps_CI_CD_Pipeline_Sample.php)

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

เว็บอ้างอิง

• Automatically Deploy Private Git Repo to Server
• รูปปกจาก http://www.mindtheproduct.com/2016/02/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/

ซี่รี่ “เริ่มต้นทำ CI/CD”

• เริ่มต้นทำ CI/CD – วิธีติดตั้ง Jenkins บน Ubuntu (1)
• เริ่มต้นทำ CI/CD – Automation Testing ด้วย PHPUnit และ Jenkins (2)
• เริ่มต้นทำ CI/CD – Automation Deploy ด้วย Git (Bitbucket) และ Jenkins (3 – จบ)

และคุณประโยชน์ที่เราจะไปใช้ Scrum เพื่อทำ Agile คือ การส่งมอบงาน หรือ Software ที่ใช้ได้ ให้ได้ไวๆ
ดังนั้น การส่งมอบให้ได้ไว คือการทำงานเป็นรอบ และการทำงานเป็นรอบ เราจะได้ผลตอบรับไว (fast feedback) ว่าใช่หรือไม่ใช่ ผิดหรือถูก

เช่นกัน Software ที่ใช้ได้และส่งมอบงานได้ไว ก็ต้องมี Automate Test ที่ทำงานได้แทนเรา และครอบคลุม หนึ่งในนั้นคือ Unit Test

ว่าแล้วก็ลองมาดูกัน

ติดตั้ง PHPUnit บน Ubuntu

ใช้คำสั่งเดียว ดังนี้

[wc_code]$ sudo apt-get install phpunit[/wc_code]

ทดสอบด้วยคำสั่ง

[wc_code]$ phpunit –version[/wc_code]

จะแสดงข้อความ ประมาณ [wc_code]PHPUnit 3.7.21 by Sebastian Bergmann.[/wc_code] ก็พร้อมใช้แล้วครับ

ติดตั้ง PHPUnit บน Windows

ซับซ้อนนิด ลองทำตามดู

1. .ไป Download PHPUnit ที่ https://phpunit.de/
2. จะได้ไฟล์ชื่อประมาณว่า phpunit-6.2.1.phar ให้เอามันไปไว้ที่ไหนโฟลเดอร์ไหนสักแห่ง ในที่นี้ผมไว้ที่ C:\bin
3. จากนั้นเข้าไปที่ windows command ด้วยการกด ปุ่มรูป windows ที่ keyboard + R
4. พิมพ์คำสั่ง
   [wc_code]cd C:\bin
   echo @php “%~dp0phpunit-6.2.1.phar” %* > phpunit.cmd[/wc_code]
5. ถ้าสังเกตในโฟลเดอร์ของเรา จะพบไฟล์ชื่อ phpunit.cmd ขึ้นมาไฟล์หนึ่ง
   
6. จากนั้นไปตั้งค่า Environment Variables และใส่ Path เป็นที่อยู่โฟลเดอร์ที่เราเก็บไฟล์ไว้ นั่นก็คือ C:\bin
   
7. คราวนี้เราจะสามารถใช้งาน phpunit ที่โฟลเดอร์อื่นๆ นอกเหนือจาก C:\bin ได้แล้ว
   

เริ่มต้นลองเขียน PHPUnit แบบง่ายๆ

สมมติว่าผมสร้างไฟล์ชื่อ Calculate.php ในนั้นมี Class ชื่อ Calculate และมี Function บวกเลขขึ้นมาตัวหนึ่ง

ผมต้องสร้างไฟล์ทดสอบขึ้นมาประกบ Function นี้ โดยผมตั้งชื่อว่า test_calculate.php และมีโค้ด ดังนี้

ไฟล์ นี้ผมจะ include ไฟล์ที่จะทำการทดสอบมาด้วย นั่นคือ Calculate.php
จากนั้นผมจะ extends เรียกใช้ตัว PHPUnit_Framework_TestCase เพื่อเรียกใช้งานคำสั่งต่างๆของ PHPUnit

class Test_calculate extends PHPUnit_Framework_TestCase

เรียกใช้ function setup() ซึ่งมันจะทำคำสั่งทั้งหมดในนี้ทุกครั้งที่มีการทดสอบ function อื่นๆ เสมอ

public function setup() {
$this->calculate = new Calculate();
}

สร้าง function ทดสอบการบวกเลขขึ้นมา โดยการตั้งชื่อของ PHPUnit จะต้องขึ้นต้นด้วย test เสมอ
และผทใช้คำสั่ง assertEquals() เพื่อตรวจสอบว่า ผลลัพธ์ที่ได้จาก $this->calculate->add($a, $b) เท่ากับ $expected หรือไม่
โดยตัวแปล $a, $b, $expected ผมให้เรียกใช้มาจากชุดตัวเลขทดสอบ ที่เก็บไว้ใน function additionProvider()
โดยวิธีการเรียกใช้นั้น คือคำสั่ง @dataProvider ที่อยู่ในกรอบคอมเม้น
/**
* @dataProvider additionProvider
*/
public function testAdd($a, $b, $expected) {
$this->assertEquals($expected, $this->calculate->add($a, $b));
}

public function additionProvider()
{
return [
‘0+0=0’ => [0, 0, 0],
‘0+1=1’ => [0, 1, 1],
‘1+0=0’ => [1, 0, 0],
‘1+4=3’ => [1, 4, 3]
];
}

จากนั้นทำการรันคำสั่ง

[wc_code]$ phpunit test_calculate.php[/wc_code]

ผลที่ได้จะเป็นดังรูปนี้

ความหมายคือ ผลการทดสอบ ไม่ผ่าน
โดยทดสอบด้วย 4 ชุดข้อมูล ไม่ผ่าน 2 ชุดข้อมูล

ให้ Jenkins ทดสอบ PHPUnit อัตโนมัติ ทุกครั้งที่มีการ Push สู่ Git

กลับไปที่ Jenkins Project ที่สร้างไว้จากบล็อก สอนติดตั้ง Jenkins
ในส่วนของ Build ให้กดปุ่ม Add build step เพื่อเพิ่มการทำงานในตอน build
จากนั้นเลือกเมนู Excute shell และใส่โค้ดไปว่า

[wc_code]phpunit –log-junit test/results/phpunit.xml test/test_calculate.php[/wc_code]

ส่วนของ test/results/phpunit.xml จะเป็น path ที่เก็บไฟล์ report, ส่วน test/test_calculate.php คือไฟล์ที่ใช้ทดสอบ
ดังนั้นใครไฟล์ทดสอบไว้อย่างไร ก็แก้กันตามนั้นส่วนไฟล์ report ก็แล้วแต่จะตั้งนะ

ต่อมา ในส่วนของ Post-build Actions ให้กดปุ่ม Add post-build action เพื่อเพิ่มการทำงานหลัง build เสร็จ
จากนั้นเลือกเมนู Publish JUnit test result report และใส่ที่อยู่ของ report เมื่อสักครู่เข้าไป

[wc_code]test/results/phpunit.xml[/wc_code]

(มันจะแจ้งตัวอักษรแดงๆ ว่าไม่พบไฟล์ก็ปล่อยมันไป)

หลังจากนั้นให้ลองกดปุ่ม Build ดู และให้กดไปที่รายการที่ Build ครั้งล่าสุด

ให้เลือกเมนู Test Result ก็จะพบผลการทดสอบที่แยก Function การทำงานพร้อม Progress Bar บอกผลด้วยว่า ผ่าน/ไม่ผ่าน กี่ Function

ในหน้าของ History ก็จะบอกประวัติของการพบข้อผิดพลาดว่ามากขึ้นหรือลดลง

เมื่อไปดูหน้าของ Project ก็จะมี Trend การพบข้อผิดพลาด

สรุป

หลังจากไดทำ Unit Test และไปให้ Jenkins เป็นตัวรันทดสอบให้อัตโนมัติทุกครั้งที่ Commit Code คราวนี้เราก็สบายใจได้แล้วว่า ทุกครั้งที่ทำงานและนำโค้ดขึ้น Git เราจะมีโค้ดที่สามารถทำงานได้ เราได้เริ่มต้นเข้าสู่ Continuous Integration ด้วย Unit Test แล้ววว

ในบล็อกตอนหน้า ผมจะนำโค้ดที่ใช้งานได้บน Git เข้าสู่ Production Server เพื่อลองทำ Continuous Deployment กันครับ

เว็บอ้างอิง

• สรุปการใช้งาน Jenkins ร่วมกับ PHP project แบบง่ายๆ
• ปรับปรุงคุณภาพของ Software ด้วย Continuous Integration Process กันนะ
• รูปปกจาก https://buddy.works/blog/introducing-phpunit

ซี่รี่ “เริ่มต้นทำ CI/CD”

• เริ่มต้นทำ CI/CD – วิธีติดตั้ง Jenkins บน Ubuntu (1)
• เริ่มต้นทำ CI/CD – Automation Testing ด้วย PHPUnit และ Jenkins (2)
• เริ่มต้นทำ CI/CD – Automation Deploy ด้วย Git (Bitbucket) และ Jenkins (3 – จบ)

Jenkins เป็น Automation Tools ที่เอาไว้ทำอะไรต่างๆแบบอัตโนมัติ ซึ่งในที่นี้เราเอามันไปใช้ทำ CI/CD เพื่อช่วยชีวิตนักพัฒนาอย่างเราให้สบายขึ้น อบย่างเช่น นักพัฒนาเพียงแค่เขียนโค้ด นำขึ้น Git แล้วให้ Jenkins ทำการทดสอบจากที่เราตั้งค่าไว้ ไม่ว่าจะ Robot Framework หรือ Test Unit ก็ตาม เมื่อผ่านเรียบร้อย ก็นำกลับไป Merge Code เข้า Git หรือจะ Deploy ต่อไปยัง Server ก็ว่ากันไป (ซึ่งผมจะเขียนบล็อกสอนทำตามนี้แหละ)

เนื่องด้วยผมใช้ Linux Ubuntu นะครับ ใครใช้ Linux/Windows อื่นๆ ก็ลองปรับๆเทียบเคียงดูอีกที

สิ่งที่ต้องมี

Server ที่ใช้ Ubuntu มี Ram ขั้นต่ำ 1GB จากนั้นให้สร้าง user ที่สามารถใช้งาน sudo ได้และใช้ File Key Authentication ในการเข้าสู่ระบบ (วิธีการสร้าง user + file key authentication + disable root user + disable password authentication)

ติดตั้ง Jenkins

เพิ่ม repository key ใน server

[wc_code]$ wget -q -O – https://pkg.jenkins.io/debian/jenkins-ci.org.key | sudo apt-key add -[/wc_code]

พิมพ์ไปแล้วจะแสดงคำว่า [wc_code]OK[/wc_code] เป็นใช้ได้ จากนั้น กำหนด Debian package repo address

[wc_code]$ echo deb http://pkg.jenkins.io/debian-stable binary/ | sudo tee /etc/apt/sources.list.d/jenkins.list[/wc_code]

ทำการ update package สักหน่อย

[wc_code]$ sudo apt-get update[/wc_code]

สุดท้ายก็พิมพ์คำสั่งติดตั้ง Jenkins

[wc_code]$ sudo apt-get install jenkins[/wc_code]

จากนั้นให้ทำการ เปิดใช้ Jenkins

[wc_code]$ sudo service jenkins start[/wc_code]

แล้วลองเช็คดูว่า Jenkins ทำงานจริงหรือไม่

[wc_code]$ sudo service jenkins status[/wc_code]

ถ้า Jenkins ทำงานอยู่ ผลลัพธ์ที่ได้จะแสดงประมาณนี้

[wc_code]Jenkins Automation Server is running with the pid 12445[/wc_code] (เลขข้างหลังอะไรก็ว่าไป อาจไม่เหมือนกัน)

เปลี่ยนเลข Port Jenkins สักหน่อย

(ถ้าใครไม่ทำตรงนี้ ก็ข้ามไปได้ครับ ใช้ Port 8080 ดังเดิม)

ปกติ Jenkins จะใช้ Port 8080 ซึ่งผมคิดว่าเกร่อไปนิด เลยอยากเปลี่ยนเป็นเลขอื่นๆแทน โดยทำดังนี้

แก้ไข file ชื่อ /etc/default/jenkins

[wc_code]$ sudo vi /etc/default/jenkins[/wc_code]

แก้เลข port บนหาบรรทัดที่เขียนว่า HTTP_PORT

[wc_code]HTTP_PORT=8083[/wc_code]

จากนั้น save แล้วออกมา restart Jenkins อีกรอบ

[wc_code]$ sudo service jenkins restart[/wc_code]

ตั้งค่าใช้งาน Jenkins

เมื่อติดตั้งและเปลี่ยน port เรียบร้อย คราวนี้มาตั้งค่ากัน โดยเข้าไปที่ URL เว็บของเราหรือ IP แล้วตามด้วยเลข Port ที่เรากำหนดเมื่อสักครู่

[wc_code]http://ip_address_or_domain_name:8083[/wc_code]

การเข้าใช้งานครั้งแรก จะขึ้นหน้าตาแบบนี้ครับ

ซึ่งมันให้เราเอารหัสเปิดใช้งานครั้งแรกมากรอก โดยพิมพ์คำสั่งดูข้อมูลจาก /var/lib/jenkins/secrets/initialAdminPassword

[wc_code]$ sudo cat /var/lib/jenkins/secrets/initialAdminPassword[/wc_code]

เราจะได้ตัวอักษรผสมตัวเลข 32 หลัก ซึ่งอันนี้แหละ เป็นรหัสที่ใช้กรอก

เมื่อกดไปขั้นต่อไป ให้เลือก Install suggested plugins เป็นค่าเริ่มต้นไปก่อน

แล้วมันจะทำการติดตั้งอะไรก็ว่าไป จนไปถึงหน้ากรอกข้อมูล Admin User ก็ตั้งได้จตามสะดวกที่ต้องการ เป็นอันเสร็จพิธี และเมื่อกดปุ่ม Start using Jenkins จะเจอหน้าแรกประมาณนี้ (Test Project กับ Test CI CD (Bitbucket) ไม่ต้องไปสนใจมันนะฮะ พอดีผมลืมแคปเจอร์หน้าตอนที่ยังไม่มี Project ขึ้น แหะๆ)

เว็บอ้างอิง

• Initial Server Setup with Ubuntu 16.04
• How To Install Jenkins on Ubuntu 16.04
• How to start Jenkins on different port rather than 8080 using command prompt in Windows?
• รูปปกจาก http://www.drdobbs.com/testing/soasta-and-cloudbees-team-for-jenkins-pl/240152753

ซี่รี่ “เริ่มต้นทำ CI/CD”

• เริ่มต้นทำ CI/CD – วิธีติดตั้ง Jenkins บน Ubuntu (1)
• เริ่มต้นทำ CI/CD – Automation Testing ด้วย PHPUnit และ Jenkins (2)
• เริ่มต้นทำ CI/CD – Automation Deploy ด้วย Git (Bitbucket) และ Jenkins (3 – จบ)