วิธีติดตั้ง

การใช้งานมี 2 แบบครับ คือใช้คำสั่ง coverlet ทำงานเลย ให้ติดตั้งด้วยคำสั่ง

dotnet tool install --global coverlet.console

หรือทำงานผ่านคำสั่ง dotnet test ให้เพิ่ม nuget package ด้วยคำสั่ง

dotnet add package coverlet.msbuild

วิธีใช้งาน

ในตัวอย่างนี้ โครงสร้างโปรเจ็คผมจะหน้าตาตามรูปภาพด้านล่าง และผมเข้าจะยกตัวอย่างคำสั่งทั้งหมดกรณีที่อยู่ในโฟลเดอร์ /tests/web.UnitTest/

ดังนั้น เมื่อต้องการดู Code Coverage ผ่านคำสั่ง coverlet

coverlet bin/Debug/netcoreapp2.1/api.dll --target "dotnet" --targetargs "test web.UnitTest.csproj --no-build" --output "../web.UnitTest.Results/Coverage.xml" --format opencover

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

• bin/Debug/netcoreapp2.1/api.dll : คือ ที่อยู่ของไฟล์ Unit Test Binary ที่เรา Build มาแล้ว
• test web.UnitTest.csproj –no-build : คือ arguments เพื่อบอกว่าเราต้องการทดสอบด้วย MSTest ไปที่ File Project ไหน, และผมเพิ่มไปว่า ไม่ต้อง ทำการ build project ใหม่ เพราะผมสั่ง build ไปแล้ว (ถ้าใครไม่สั่ง build ก่อน ให้เอา –no-build ออกด้วยนะ)
• ../web.UnitTest.Results/Coverage.xml : คือ ที่อยู่ของไฟล์ report ซึ่งผมให้ใช้เป็น Formet ของ OpenCover จึงจ้องมีนามสกุล .xml (ค่ามาตรฐาน ถ้าไม่ระบุ มันจะเป็น JSON)
• opencover : คือ Format ของไฟล์ report ที่เราจะนำไปใช้งานต่อ

ลองมาดูการใช้งานผ่านคำสั่ง dotnet test แบบปกติบ้าง

dotnet test --no-restore --no-build --logger:"trx;LogFileName=Results.trx" --results-directory:"../web.UnitTest.Results" /p:CollectCoverage=true /p:CoverletOutput="../web.UnitTest.Results/Coverage.xml" /p:CoverletOutputFormat=opencover

ถ้าให้เดาค่าต่างๆ คงพอเดากันได้นะครับ ระบุเหมือนด้านบนเลย แต่คำสั่งหนึ่งที่ต้องมีเสมอคือ

/p:CollectCoverage=true 

เพื่อบ่งบอกว่า เราต้องการ Generate Code Coverage ออกมาด้วย

การแสดงผล

เมื่อรันคำสั่งตามด้านบนเรียบร้อยแล้ว จะได้หน้าตาประมาณนี้ครับ

ความหมายที่ได้จากการแสดงผล คือ

• Module : ชื่อ System ที่มันทำการทดสอบ
• Method coverage : จำนวนของ Function/Method ที่ถูกเรียกใช้งาน
• Branch coverage : จำนวนของ Branch หรือเงื่อนไขใน if statement ถูกเรียกใช้งานทั้ง true และ false
• Line coverage : จำนวนของบรรทัดที่ถูกเรียกใช้งาน

อ้างอิงคำอธิบายจาก http://www.somkiat.cc/introduction-to-code-coverage/

กำหนดคุณภาพ ด้วยการตั้ง Threshold

คราวนี้ ถ้าเราอยากตั้งค่าว่า ถ้า Code Coverage เรามี Test ครอบคลุมต่ำกว่า xx% เราจะไม่ให้ผ่านการทดสอบ โดยเพิ่ม Argument ชื่อ threshold ลงไป ดังนี้

ตัวอย่างด้วยคำสั่ง coverlet

coverlet bin/Debug/netcoreapp2.1/api.dll --target "dotnet" --targetargs "test web.UnitTest.csproj --no-build" --output "../web.UnitTest.Results/Coverage.json" --threshold 80

ตัวอย่างด้วยคำสั่ง dotnet test

dotnet test --no-restore --no-build --logger:"trx;LogFileName=Results.trx" --results-directory:"../web.UnitTest.Results" /p:CollectCoverage=true /p:CoverletOutput="../web.UnitTest.Results/Coverage.xml" /p:CoverletOutputFormat=opencover /p:Threshold=80 /

ซึ่งในตัวอย่างผมกำหนดว่า Coverage ทุกประเภทจะต้องเกิน 80% ถึงจะเรียกว่าผ่าน ถ้าต่ำกว่านั้นจะ Fail ทันที ดังรูปด้านล่าง

และเราสามารถกำหนดเฉพาะ Coverage ได้ด้วย เช่นผมต้องการเช็คเฉพาะ Line Coverage ก็สามารถเพิ่ม Argument เข้าไป ดังนี้

ตัวอย่างด้วยคำสั่ง coverlet

--threshold-type line

ตัวอย่างด้วยคำสั่ง dotnet test

 /p:ThresholdType=line

ผลที่ได้คือ

สรุป

ถ้าเทียบกับ minicover แล้ว ตัวนี้ค่อนข้างใช้งานง่าย ไม่ซับซ้อนมากนัก รองรับ .Net Core 2.2.1 ตัวล่าสุดด้วย และสามารถแจกแจงรายละเอียด ตาม Coverage Type ต่างๆ พร้อมออก Report ได้ เช่น json, lcov, opencover (xml file), cobertura (xml file) และ teamcity ถ้าสนในรายละเอียดมากกว่านี้ ไปดูได้ที่ Github ของผู้พัฒนาได้เลยครับ ที่ https://github.com/tonerdo/coverlet

Featured image from: https://www.aapnainfotech.com/test-coverage-much-testing-enough/

ทบทวน “5 คุณสมบัติของ Unit Test ที่ดี” อีกครั้ง

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

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

คราวนี้ การที่ Unit Test ของเราต้องไปทำงานร่วมกับสิ่งอื่นๆ มันมักทำให้ขัดแย้งกับ 5 ข้อ ข้างต้น เช่น

• เมื่อเราต้องการทดสอบ Function ที่ต้องต่อกับ Database มันก็จะทำงานไม่เร็ว เพราะ Query นาน, มันทำซ้ำไม่ได้ เพราะต้องเพิ่มลบข้อมูลจาก Database ตลอด แล้วไหนจะกระทบตัวอื่นๆที่อาจจะใช้ Database เดียวกันด้วย
• เมื่อเราต้องการทดสอบ Function ที่ต้องต่อกับ API ภายในของเราเอง หรือภายนอก มันก็ทำงานไม่เร็ว เพราะมีเรื่องของความเร็ว Network/Internet ซึ่งถ้า Internet ล่ม ก็ทำซ้ำไม่ได้ หรือถ้าส่งข้อมูลไปให้แล้วบาง API ก็ส่งข้อมูลซ้ำไม่ได้ เช่น ส่งข้อมูลไป API สมัครสมาชิกที่มีเงื่อนไขสมัครด้วยอีเมลเดียวเท่านั้น
• เมื่อเราต้องการทดสอบ Function ที่ต้องไปทำงานร่วมกับ Function อื่น แต่มันยังทำไม่เสร็จหรือไม่ได้ทำ เราก็ทดสอบไม่ได้อยู่ดี

ดังนั้น ถ้าต้องการให้ Unit Test ของเราทำงานได้ตามคุณสมบัติดังกล่าว เราจะต้องสร้างการทำงานสิ่งอื่นๆที่เกี่ยวข้องขึ้นมา ซึ่ง จะมีอยู่  5 ประเภท เรียกรวมๆ ว่า Test Doubles

Test Doubles คืออะไร

Image from: https://blogs.sap.com/

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

คำว่า Test Doubles มาจากหนังสือที่ลุง Gerard Meszaros เขาเขียนมันขึ้นมา โดยแปลงมาจากคำว่า Stunt Double ที่ใช้ในการทำหนัง ซึ่ง Stunt Double คือ สตั๊นแมนหรือนักแสดงที่มีหน้าตา รูปร่าง แต่งตัวคล้ายกับพระเอก แล้วออกไปแสดงแทนพระเอกในบางฉาก

คราวนี้พอมาเป็น Test Doubles โดยอธิบายมุมเดียวกับ Stunt Double มันก็คือ อะไรบางอย่างที่เราทำมันขึ้นมาเพื่อให้มันทำงานแทนของจริง ในขณะที่เราไม่ได้ต้องการทดสอบมัน อย่างเช่น API ของคนอื่น, Class/Function ของคนอื่น, Database  เป็นต้น

Test Doubles 5 ประเภท มีอะไรบ้าง

อย่างที่บอก ว่าเราเคยเรียกทุกสิ่งที่ถูกจำลองว่า Mock  แต่เมื่อพิจารณาดีๆ มันมีจุดแตกต่างกัน ซึ่งเราจะใช้การเรียกประเภทต่างๆ อ้างอิงตามที่ลุง Gerard Meszaros ได้เขียนอธิบายไว้ และทั่วโลกก็ใช้เรียกตามนี้เช่นกัน ดังนั้นเวลาใช้สื่อสารเราจะได้เข้าใจตรงกัน

ปล. ตัวอย่างที่จะใช้ต่อไปนี้ เขียนด้วย .Net Core 2

1. Dummy

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

ถามว่าโง่ได้ขนาดไหน ก็เช่น สร้าง Class เปล่าๆ หรือ Function ที่คืนค่า null หรือ throw exception ก็ยังได้ โดยไม่ต้องสนใจว่ามันทำงานอย่างไร เราสนแค่ว่า ตัวที่เราจะทดสอบสามารถเรียกมันแล้วผ่านไปได้โดยไม่ติดขัด

ตัวอย่าง Dummy

ผมมีโค้ดสำหรับการ Login โดย Constructor Member() จะเป็นส่ง Username/Password ไปตรวจสอบ ซึ่งถ้าถูกต้อง ก็จะทำงานต่างๆ ได้ เช่น แสดงข้อความ “Welcome to member area” ใน method Profile()

View the code on Gist.

ผมสร้าง Interface ขึ้นมาชื่อ IAuthorize และคลาสที่ถูกนำไปใช้งานคือ Authorize โดยภายในนั้นมี CheckAuthorize() ซึ่งจะทำการตรวจสอบว่า Login ถูกต้องหรือไม่

และผมสร้างคลาสอีกตัวชื่อ DummyAuthorize เพื่อที่จะใช้ทดสอบ โดยผมไม่ได้ return อะไรออกไปว่าเป็น true/false มีเพียงส่งค่าว่างเปล่าประเภท Boolean ออกไป

View the code on Gist.

มาดูในไฟล์ Unit Test ซึ่งผมต้องการตรวจสอบว่าสามารถสร้าง Object ของ Member ได้หรือไม่ แต่ติดว่า มันต้องใส่ Username/Password ใน Constructor ด้วยทุกครั้ง ดังนั้น ผมจึงใช้ DummyAuthorize แทน เพื่อให้มันทำงานทะลุผ่านไปได้

View the code on Gist.

นี่แหละครับ การทำงานของ Dummy ใส่อะไรไปแล้วใช้แทน Dependency ตัวอื่นๆ ได้ เพื่อทะลุไปทำงานอย่างอื่นต่อตามที่ต้องการ ซึ่งในตัวอย่างนี้ ผมลองเช็ค Type Object  Member ดู

2. Stub

Stub คือการกำหนดสถานะหรือสิ่งต่างๆให้เป็นไปตามที่เราต้องการ (State verification) โดยหน้าตาจะคล้ายกับ Dummy แต่ Stub เราจะต้องกำหนดค่าที่จะใช้ด้วย เพื่อให้ได้ผลลัพธ์ออกมาตามที่เราต้องการ

เช่น Test Case ของสมการ 1 + X จะต้องได้เท่ากับ 2 โดยที่ X คือ Function ภายนอกที่เราไปเรียกใช้ และผลลัพธ์จะต้องออกมาเป็น 2 เสมอ ดังนั้น เราจะต้องกำหนดค่า X ว่าต้องเป็น 1 เท่านั้น (ซึ่งต่างจาก Dummy ที่ไม่สนใจการระบุค่า)

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

ตัวอย่าง Stub

ผมอ้างอิงจากโค้ดชุดเก่าของ Dummy แต่เปลี่ยน Unit Test ใหม่ โดยผมต้องการตรวจสอบว่า เมื่อเรียกใช้ Profile() จะต้องแสดงข้อความ “Welcome to member area” ขึ้นมา

View the code on Gist.

และเช่นกัน ผมสร้าง Class ชื่อ StubAuthorize จาก IAuthorize และใน CheckAuthorize() จะระบุเป็น true เสมอ เพื่อให้ Unit Test ผมแสดงข้อความ “Welcome to member area” ขึ้นเสมอ

View the code on Gist.

อาจจะมีความสงสัยว่า ถ้าเราใส่ Username/Password เข้าไปตอนสร้าง object Member เลยได้ไหม อย่างไรก็คืนค่าเป็น  true เสมอ ตอบเลยว่าได้ แต่มีจุดให้คิดเพิ่ม คื อ

1. เราต้องการตรสวจสอบการเรียกใช้ Profile() ว่าแสดงผลถูกต้องหรือไม่ ในสถานะที่เราต้องการให้มันทำงานถูกต้อง ดังนั้นเราไม่ได้ต้องการตรวจสอบ CheckAuthorize() ว่าทำงานถูกต้องหรือไม่ อันนี้จะเขียนเป็นอีก Unit Test หนึ่ง (แต่ก็ไม่ผิดนะครับ เพราะเป็นรูปแบบ Unit Test – Sociable ซึ่งลองอ่านได้ที่ รูปแบบการทดสอบของ Unit Test)
2. แน่ใจหรือไม่ว่า Username/Password ที่ใส่ค้างไว้ จะไม่เปลี่ยนในภายหลัง

3. Mock

ชื่อนี้สร้างความสับสนกันทั้งโลก ซึ่ง Mock ใน Test Doubles จะหมายถึง การทดสอบพฤติกรรมการทำงานของสิ่งๆหนึ่ง (Behavior Verification) อย่าง Class/Function เป็นต้น ว่าทำงานตามที่เราต้องการหรือไม่

กล่าวคือ Mock ไม่ได้สนใจผลลัพธ์ปลายทาง แต่สนใจการทำงานของสิ่งที่ต้องการทดสอบ เช่น ส่งค่าเข้าไปใน process แล้วค่านั้นมีการเปลี่ยนแปลงไปตามที่เราคาดหวังหรือไม่

ตัวอย่าง Mock

ระบบ Login ที่ผมสร้างไว้ จะระบุ Username/Password ผ่าน Constructure ชื่อ Member() จากนั้นจะทำการส่งต่อไปให้ CheckAuthorize() เพื่อตรวจสอบว่าถูกต้องหรือไม่ โดยถ้า ถูกต้อง มันจะแสดงผลออกมาที่ Profile() ว่า “Welcome to member area”

ดังนั้น Unit Test ผมจะมีหน้าตาประมาณนี้ ซึ่งผมจะ Assert ไปสองค่าว่า มีการใช้งาน CheckAuthorize() และผลลัพธ์ที่ได้คือ “Welcome to member area”

View the code on Gist.

จากนั้นผมสร้าง Class ชื่อ MockAuthorize จาก IAuthorize โดยผมสร้างตัวแปร checkAuthorizeWasCalled ขึ้นมา เพื่อใช้ตรวจสอบการทำงาน

View the code on Gist.

ซึ่งถ้าพฤติกรรมการทำงานของโค้ดผมถูกต้อง จะต้องมีขั้นตอนคือ

1. ส่ง Username/Password ผ่าน Constructure ชื่อ Member()
2. จากนั้นส่งต่อไปให้ CheckAuthorize()
3. เปลี่ยนค่าตัวแปร checkAuthorizeWasCalled จากค่า  false เป็น true
4. โยนกลับมาที่ Profile() ให้แสดงผลลัพธ์

เป็นอันว่าพฤติกรรมของ Login ของผมมีการเรียกใช้ CheckAuthorize() เพื่อตรวจสอบ Username/Password ถูกต้องนะ

ตัวอย่าง Mock โดยการใช้ Moq4

คราวนี้เมื่อเราเข้าใจวิธีการปกติแล้ว ลองดูตัวอย่างโค้ดของการใช้ Library ชื่อ Moq4  ซึ่งจะทำให้ง่ายขึ้น เพราะสร้างตัว Mock CheckAuthorize() ไว้ใน Unit Test ได้เลย จากนั้นผม Create Object ขึ้นมา และทำการ Verify ว่ามีการเรียกใช้ CheckAuthorize() เกิดขึ้นหรือไม่

View the code on Gist.

4. Spy

ชื่อนี้แปลตรงตัวคือ สายลับ โดยเราจะส่งสายลับไปดูว่า ระบบของเรามีการเรียกใช้ Function ที่เราต้องการทดสอบจริงๆไหม ซึ่งคล้ายกับ Mock แต่แค่ไม่ได้สนใจพฤติกรรมว่าทำอะไรไปบ้าง ต้องได้ค่าอะไร (Exclusive Behavior Verification)

เช่น เรามีระบบรายชื่อที่จะต้องส่งอีเมลออกไป 100 รายการ ระบบของเราจะต้องมีการเรียก Function การส่งอีเมลเป็นจำนวน 100 รอบ ตามที่ต้องการจริงๆ

ตัวอย่าง Spy

ผมทำการสร้าง object Member ขึ้นมาสองครั้ง โดยมันจะต้องไปเรียกใช้งาน CheckAuthorize() จำนวนสองครั้งเช่นกัน ดังนั้นผมจึงทดสอบว่ามีการเรียกใช้งานจำนวนสองครั้งจริงหรือไม่

View the code on Gist.

จากนั้นผมสร้าง Class ชื่อ SpyAuthorize จาก IAuthorize โดยผมสร้างตัวแปร checkAuthorizeWasCalled ขึ้นมา เพื่อใช้นับจำนวนการเรียกใช้งาน

View the code on Gist.

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

5. Fake

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

โดยกรณีนี้ถูกยกตัวอย่างขึ้นมาชัดเจน ก็คือ การใช้ In-Memory เก็บข้อมูลสำหรับทดสอบ แทนการใช้ Database จริงๆ  เป็นต้น

เช่น ระบบมีการสร้าง Order ไว้ใน Database แต่ไม่อยากสร้างจริงใน Database เพราะจะทำให้เลข Order ID ถูกเพิ่มจำนวนเข้าไป และก็ห้ามลบออกด้วย เพราะ Order ID จะขาดช่วง, ดังนั้นเราจะต้องสร้าง Database จำลองขึ้นมา ซึ่งถ้าให้ทุกเครื่องต้องทดสอบได้ และมีความเร็วมากๆ เราก็ต้องใช้ In-Memory นั่นเอง

ตัวอย่าง Fake

ผมต้องการทดสอบว่า Function ชื่อ Get_Member_Information_By_ID() สามารถส่ง Member ID เข้าไป และคืนค่าจาก Database เป็นไปตามที่ผมกำหนดหรือไม่ ดังนั้น แทนที่ผมจะเรียกใช้ Database จริง ผมจึงสร้าง In-Memory Database ขึ้นมาก้อนหนึ่งชื่อ get_by_id_members และทำการใส่ข้อมูลเข้าไปก่อน จากนั้นส่ง Member ID 1 เข้าไปให้ Get_Member_Information_By_ID และทำการตรวจสอบว่า ได้ชื่อ เบอร์โทร วันเดือนปีเกิด ตามใน Database จริงๆหรือไม่

View the code on Gist.

สรุป

Test Doubles มี 5 ประเภท ที่จะนำไปเลือกใช้ได้ตามสมควร

1. Dummy: ใช้อะไรก็ได้เพื่อ By Pass การทำงาน แทนการใช้ Dependency จริง
2. Stub: กำหนดค่าบางอย่าง เพื่อให้ได้ผลลัพธ์เป็นค่าที่เราต้องการเสมอ
3. Mock: เพื่อ verify ว่า process ที่เรียกใช้ มีการส่งค่าไปหา Dependency ตรงตามที่เราคาดหวังหรือเปล่า
4. Fake: จำลองบางอย่างขึ้นมาเพื่อใช้แทนของจริง
5. Spy: เพื่อ verify ให้แน่ชัดในการใช้ process เช่น โดนเรียกใช้ไปกี่ครั้ง หรือพารามิเตอร์อะไรถูกส่งไปบ้าง

หากต้องการเขียน Unit Test เราเลี่ยงไม่ได้ที่จะต้องเรียนรู้เรื่อง Test Doubles เพื่อตัดการเกี่ยวข้องกับสิ่งต่างๆ ทรี่ไม่จำเป็นออก (Dependency) เพราะว่า เราต้องการเจาะจงทดสอบเพียงอย่างเดียวเท่านั้น อย่างอื่นที่ไม่ทดสอบ เราก็จำลองขึ้นมาโดยใช้ Dummy, Stub, Fake ตามแต่จะเลือกใช้ และเราก็ใช้ Mock, Spy เพื่อทดสอบว่าโค้ดที่เขียน มันได้ทำงานถูกต้องจริงๆใช่ไหม ซึ่งวิธีการนี้ นำไปใช้ได้กับทุกภาษาโปรแกรม

และถ้าสังเกตให้ดี จะใช้ Test Double ได้ จำเป็นต้องรู้เรื่อง Unit Test,  Dependency-Injection และการเขียนโปรแกรมแบบ  Object-Oriented ด้วยนะฮะ ไม่เช่นนั้น เข้าใจยากเลยทีเดียว

อ้างอิง

• Test Doubles: mocks, dummies and stubs  << ตัวอย่างน่าสนใจ เข้าใจง่ายดี
• Test Doubles — Fakes, Mocks and Stubs. << แนะนำให้อ่านครับ สรุปเข้าใจง่าย ตัวอย่างดี อ่านง่าย
• The Little Mocker << แนะนำให้อ่านครับ  อ่านง่าย ตัวอย่างเข้าใจง่ายมาก บทความนี้เขียนจากพื้นฐานเว็บนี้
• Mocks Aren’t Stubs << แนะนำให้อ่านครับ อธิบายละเอียดเลย
• Understanding Test Doubles (Mock vs Stub) << แนะนำให้อ่านครับ สรุปสั้นๆ ตัวอย่างดี อ่านง่าย
• มาดูกันว่า Mock, Stub และ Dummy แตกต่างกันอย่างไร ? << ผมอ้างอิงการแปลภาษาไทยจากเว็บพี่ปุ๋ย
• และสุดท้าย กราบขอบพระคุณพี่บอย Elder แห่งสยามชำนาญกิจ ที่ช่วยอ่านรีวิวและแนะนำมา ณ ที่นี้ครัช

โพสต์นี้ผมจะอ้างอิงถึงลุง Martin Fowler เยอะหน่อย เพราะไปอ่านที่แกอธิบายไว้เรื่อง UnitTest และ Mocks Aren’t Stubs ได้น่าสนใจมาก

ถ้าถามว่า Unit Test คืออะไร ต้องทดสอบในหน่วยย่อยขนาดไหน ไม่มีใครสามารถตอบได้ แม้แต่ลุง Martin Fowler และ Kent Beck เพราะนิยามของแกก็เปลี่ยนไปตามงานที่ทำ แต่ไม่ว่าจะนิยามอย่างไร มันจะมีลักษณ์เหมือนกัน 3 ข้อ คือ

1. มุ่งทดสอบในหน่วยที่เล็กที่สุดของระบบ – นั่นสิ แล้วระบบเรามีหน่วยย่อยสุดแค่ไหน ต้องกลับไปดูว่าเราออกแบบไว้อย่างไร
2. เขียนโดยโปรแกรมเมอร์ ด้วยเครื่องมือที่ถนัด  – ใช่แล้ว เป็นโปรแกรมเมอร์เขียนนะ ไม่ใช่ Tester!, และจะใช้เครื่องมืออะไรก็ตามถนัดเลย จะเขียนเช็เทียบค่าเอง หรือใช้ Unit Test Framework เช่น xUnit ก็ตามสะดวก
3. มีการทดสอบที่ได้ผลลัพธ์ออกมาเร็วมากๆ – เห็นผลในระดับเสี้ยววินาที (millisecond)

ข้อ 2, 3 ยังพอเข้าใจได้ แต่ข้อ 1 ขอบเขตยังไม่ชัดเจนนัก แต่อย่างที่ผมบอก มันอยู่ที่การออกแบบซอฟต์แวร์เราแต่แรกว่าย่อยได้ขนาดไหนและครบถ้วนหรือไม่ (ดังนั้นจึงเป็นที่มาว่าทำไมซอฟต์แวร์ที่พัฒนาโดยใช้หลักการ Test-Driven Development ถึงสามารถเขียน Unit Test ได้ครบ, ครอบคลุม และมีโครงสร้างระบบที่สามารถทดสอบได้ตั้งแต่ต้น)

การออกแบบซอฟต์แวร์ของเรา หลีกเลี่ยงไม่ได้ที่จะมี Method ที่ทำงาน 2 แบบ คือ ทำงานจบได้ในตัวมันเอง กับ ต้องอาศัย Method อื่นๆ มาประกอบกันเพื่อทำงาน

ซึ่งการทดสอบของ Unit Test ก็เช่นกัน ได้จำแนกออกเป็น 2 แบบตามการทำงานของ Method คือ

Unit Test ที่ทดสอบแบบ Solitary

คือทดสอบการทำงานเพียง​ Method เดียวเท่านั้น เช่น เรามีระบบที่ให้สมาชิกสามารถโอนเงินได้และคิดค่าธรรมเนียม ดังนั้นเราจะทดสอบเฉพาะ Method การคิดค่าธรรมเนียม โดยไม่เอา Method ทำงานเรื่องสมาชิกและการโอนเงินเข้ามาเกี่ยวข้องเลย ดังนั้น จะต้องออกแบบให้แยกจากกันให้ดี และใช้หลักการของ Test Doubles เช่น Mock หรือ Stub เข้ามาจำลองการทำงานอื่นๆ (ส่วนของสมาชิก, โอนเงิน) ที่เราไม่ต้องการทดสอบ

Unit Test ที่ทดสอบแบบ Sociable

คือทดสอบการทำงานของ Method ที่เกี่ยวข้องกับ Method อื่นๆ ด้วย ซึ่งลุง Martin บอกว่าในสมัยยุค 90 ที่ xUnit เพิ่งจะเกิด รูปแบบ Sociality นี้ได้รับความนิยมมาก เพราะมันทำได้สะดวกกว่าแบบ Solitary

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

ต่อมาในช่วงปี ค.ศ. 2000 ที่ xUnit เป็นที่นิยมแล้ว การทดสอบแบบ Solitary ก็กลับมาบูมอีกครั้ง เพราะมีเครื่องมือที่ช่วยในการทำ Mock เกิดขึ้นมากมาย จนได้เกิดสำนักที่เขียน Unit Test ขึ้นเป็นสองสำนักใหญ่ๆ (School) คือ

Classical (หรือเรียกว่าชาว Classicist, หรือสำนัก Detroit)

คือใช้รูปแบบการทดสอบแบบ Sociable เน้นทดสอบโดยใช้ Object, Method, Properties จริงๆ มีการอ้างอิง Method ถึงกันก็ปล่อยมันไป เพื่อให้เห็นพฤติกรรมจริงๆของมัน, แต่ทั้งนี้ ก็มีใช้ Mock ด้วย แต่เท่าที่จำเป็นเท่านั้น อย่างการเชื่อมต่อ Database, Network

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

ที่มาของชื่อ Detroit เพราะมันถูกใช้ใน XP Programming ครั้งแรกกับโปรเจ็ค C3 ของ บริษัท Chrysler ในเมือง Detroit

Mockist (หรือเรียกว่าชาว Mockist, หรือสำนัก London)

คือใช้รูปแบบการทดสอบแบบ Solitary ที่ทำงานเดียวเท่านั้น ดังนั้นจะต้องตัดตัวเกี่ยวข้องออก มีการใช้ Mock, Stub เข้ามาสร้างตัวจำลองของ Object, Method, Properties เสมอๆ

โดยกลุ่ม Mockist จะเป็นพวกเน้นใช้ Mock เพื่อทดสอบพฤติกรรมการทำงานของ Method นั้นๆ (Behavior verification) ว่าทำงานได้ตามที่คาดหวังหรือไม่ เช่น ส่งข้อมูลเข้าไป Method เพื่อบันทึกข้อมูล จะเห็นว่ามีการบันทึกข้อมูลเกิดขึ้นเสมอ เป็นต้น

ที่มาของชื่อ London คือ ถูกใช้โดยกลุ่มคนใช้ XP Programming ในยุคเริ่มแรกในเมือง London

…

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

และที่สำคัญลุง Martin มองว่า ถ้าต้องไปเชื่อมต่อกับระบบภายนอกเช่น I/O, Database, Network ที่มันมีความเสถียรพอ และมีความเร็วมากพอ ก็สามารถเอามาใช้ใน Unit Test ได้นะ เช่น จำลอง MySQL Database ด้วย In-Memory Database เป็นต้น

แล้วจะเลือกอะไรดีระหว่าง Classicist หรือ Mockist

จากทั้งหมดที่เขียนเล่ามา ไม่ว่าจะความเห็นส่วนตัว หรือความเห็นของลุง Martin เอง ทั้งสองแบบดีหมด ไม่จำเป็นต้องไปเลือกมันหรือต้องไปสนใจว่า Method นี้จะทดสอบด้วยอะไร มันอยู่ที่ว่าเราเข้าใจหรือเปล่าว่า Unit Test คืออะไร และเราจะทดสอบอะไร

ถ้า Method มันทำงานจบในตัวเอง หรือมีการใช้ Method อื่น แบบง่ายๆ สามารถแยกการทำงานได้ แยกการทำสอบได้ เราก็ไม่จำเป็นต้องไปจำลอง Object โดยใช้ Mock, Stub หรืออื่นๆใน Test Doubles เลยก็ได้

แต่ถ้ามันดูยุ่งยาก และจำเป็นต้องเชื่อมต่อกับส่วนอื่น และมันทำให้การทดสอบช้าลง หรือไม่เสถียร เช่น Network, Database แบบนี้เราก็เลี่ยงไม่ได้ที่จะต้องใช้ Test Doubles นะ

สรุป

• เราจะใช้ Unit Test ที่มีรูปแบบการทดสอบเป็น Classical หรือ Mockist ก็ได้ ไม่มีผิดไม่มีถูก
• แยกการทำงานของ Method ให้ทำงานทีละอย่าง
• ถ้า Method ไหนมีแต่ Business Logic – เป็น Classical
• ถ้า Method ไหนมี Business Logic โดยจำเป็นต้องข้องเกี่ยวกับ Method อื่นที่คุมไม่ได้ หรือระบบภายนอก – เป็น Mockist
• ถ้า Method ไม่มี Business Logic และไปข้องเกี่ยวกับอื่นที่คุมไม่ได้ หรือระบบภายนอก – เป็น Mockist
• จะแยกแยะได้ขนาดนี้ แปลว่าต้องทำ High Level Design และ Detail Level Design
• ถ้าจะทำให้เขียน Unit Test ให้ง่าย ควรเริ่มด้วย Test First และ Test-Driven Development
• ถ้าอ่านโพสต์นี้แล้วไม่เข้าใจ ต้องไปเรียนรู้ Unit Test และ Test Doubles เพิ่มนะ
• พอเขียนเสร็จ รู้สึกว่าตัวเองต้องไปเรียนรู้เรื่อง OOP, SOLID ให้มากขึ้น

อ้างอิง

• UnitTest< (อ้างอิงจากที่นี่ และรูปในโพสต์นี้ก็ใช้จากบทความนี้)/li>
• Mocks Aren’t Stubs
• State vs Behaviour Verification

• กระบวนการคิดเพื่อเตรียมทำ 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)