วิธีติดตั้ง

การใช้งานมี 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/

เรื่องเหล่านี้บางคนอาจไม่ค่อยอินเท่าไร หากทำงานคนเดียว หรืองานที่เร่งด่วนมากๆ (“งานร้อน” นั่นหละ) โดยเฉพาะงานทำครั้งเดียวเสร็จ ส่ง รับเงิน แล้วก็แยกย้าย.. แต่กับอีกหลายคนที่ต้องทำงานเป็นทีม หรือมี QA , CTO, Team Lead คอยเข้ามาตรวจสอบการทำงานของ Software และ Review Code อยู่สม่ำเสมอ ก็คงต้องปวดหัวกลับมาแก้งานรายชั่วโมง จนไม่ต้องทำมาหากิน

วันนี้เลยเอาเครื่องมือว้าวๆ ตัวหนึ่งชื่อ SonarQube มาให้ลอง มันเป็นตัวที่ช่วยตรวจสอบคุณภาพของ Source Code ให้เราได้แบบอัตโนมัติ 

ความสามารถของ SonarQube หลักๆ มีดังนี้

• ตรวจหาข้อผิดพลาด (Bugs) ใน Source Code
• ช่วยค้นหาพวก Source Code ที่แย่ๆ ซับซ้อน มีกลิ่นตุๆว่าจะเป็นปัญหาในอนาคต (Code Smells)
• ช่วยค้นหาช่องโหว่ต่างๆ ที่เป็นข้อผิดพลาดหรือปัญหาด้านความปลอดภัย (Vulnerabilities)
• กำหนดค่าของคุณภาพที่จะให้ผ่านได้ด้วยนะ (Quality Gate) เช่น ต้องมี Code Coverage 80%
• ทำงานร่วมกับ Automation Tools เช่น Jenkins เพื่อทำ Continueus Integration ได้ (Continuous Code Quality)
• รองรับการตรวจสอบภาษาฮิตๆ ได้มากกว่า 20 ภาษา เช่น Java, PHP, C#, Python, Swift, C/C++, Javascript ฯลฯ
• ทั้งหมดนี้… ฟรี!! (Open Source)

แค่อ่านความสามารถจบก็ โครต “ว้าว!!” ตามที่บอกเลยปะล่ะ

ลองติดตั้ง SonarQube Server กัน

ถ้าใครใช้ Docker ก็ติดตั้งไม่ยาก จะใช้ sonarqube ที่ hub.docker หรือ git ของผมก็ได้ (เอา official มาปรับนิดหน่อย ใส่ extension + ทำเป็น docker-compose)

ถ้าใช้ official ก็ทำคำสั่งง่ายๆเลย คือ

[wc_code]$ docker run -d –name sonarqube -p 9000:9000 -p 9092:9092 sonarqube[/wc_code]

แต่ถ้าไม่ได้ใช้ Docker ก็ไปหาติดตั้งได้ที่นี่ครับ https://www.sonarqube.org/downloads/

เวลาใช้งาน Server จะเข้าผ่าน URL

[wc_code]http://localhost:9000[/wc_code]

ติดตั้ง

ติดตั้ง SonarQube Scanner

หลังจากมี Server สำหรับเก็บรวบรวม Report แล้ว จะต้องมีตัว Scanner เพื่อทำการประมวลผล Source Code ของเราเพื่อส่งเข้าไปทำ Report ซึ่งตัวนี้เรียกว่า SonarQube Scanner

โดยตัวมาตรฐาน จะสามารถดาวโหลดได้ที่
https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner

ที่ผมบอกว่าเป็นตัวมาตรฐาน เพราะมีภาษาบางภาษาจะต้องใช้ Scanner ที่ทำมารองรับภาษาของตัวเอง เช่น .Net Core จะต้องใช้ SonarQube Scanner for MSBuild เท่านั้น ถึงจะอ่าน Source Code ออก เป็นต้น ดังนั้น ลองดูความเหมาะสมของภาษาที่ตนเองใช้ และโหลดตามลิงค์ด้านล่างได้เลยครับ

• SonarQube Scanner for MSBuild: Launch analysis of .Net projects
• SonarQube Scanner for Maven: Launch analysis from Maven with minimal configuration
• SonarQube Scanner for Gradle: Launch Gradle analysis
• SonarQube Scanner for Ant: Launch analysis from Ant
• SonarQube Scanner For Jenkins: Launch analysis from Jenkins
• SonarQube Scanner: Launch analysis from the command line when none of the other analyzers is appropriate

สร้างไฟล์ Sonar Config

ในการสั่งให้ Scanner ทำงานอ่าน Source Code ใดๆ จะต้องสร้าง Config ไว้ในโฟลเดอร์ของ Source Code นั้นไว้ด้วย

โดยไฟล์ที่สร้างจะชื่อว่า “sonar-project.properties” และข้อมูลหลักๆที่ใส่คือ

# SonarQube server
sonar.host.url=http://localhost:9000

# must be unique in a given SonarQube instance
sonar.projectKey=my:project

# this is the name and version displayed in the SonarQube UI. Was mandatory prior to SonarQube 6.1.
sonar.projectName=My project
sonar.projectVersion=1.0

# Path is relative to the sonar-project.properties file. Replace “\” by “/” on Windows.
# This property is optional if sonar.modules is set.
sonar.sources=.

# Encoding of the source code. Default is default system encoding
#sonar.sourceEncoding=UTF-8

เช่น ผมจะให้ Scan Source Code ของ PHP Project เพื่อทำ report ไว้บน Docker บนเครื่องผมเอง

เมื่อกดเข้าไปดูรายละเอียดของ Project จะบอกเลยครับว่า มี Bug เท่าไร, Code Smell เท่าไร ฯลฯ

กดเข้าไปดูรายละเอียดลึกลงไปอีก ก็จะเห็นว่ามีปัญหาอะไรที่ไฟล์ไหน เพื่อให้เราแก้ไข (ซึ่งบางที ปัญหาหลายอย่างที่พบ ก็อาจไม่ได้ส่งผลให้ Software ทำงานผิดพลาด แต่แค่ไม่เป็นไปตามมาตรฐานนั่นเอง)

สรุป

ลองใช้ดูแล้ว สนุกมากครับ ช่วยเราหา Bug หาโค้ดที่ไม่ดีได้ อ่านไปก็แก้ไป จำไป ดีต่อการพัฒนาความรู้ตัวเอง แต่สิ่งที่ต้องระวังและที่ผมพบปัญหาคือ บางทีติดตั้ง Scanner สำหรับใช้ในภาษาต่างๆ พอใช้แล้วปรากฎว่า ได้เกรด A ทุกหัวข้อ ไม่มี Code Smell ไม่มีข้อผิดพลาดอะไรเลย ซึ่งก็อย่าไปเชื่อมันนะครับ ปัญหานี้เกิดจากมัน Analyst Code ไม่ได้ เลยทำให้ไม่เจอปัญหา แล้วไอ้เจ้า SonarQube ก็ดันไม่แจ้ง Error อะไรมาด้วยว่ามัน Analyst ไม่ได้ ซึ่งจุดนี้ต้องทดสอบ Code ให้มันแบบ Pass และ Fail คู่กัน ให้เห็นว่ามันทำงานได้จริงไหม

เมื่อใช้คล่องตัวแล้ว เอามันไป Integrate กับ Jenkin เพื่อทำ CI/CD ก็ได้นะครับ เช่น เมื่อ Test ผ่านหมดแล้ว ก็ให้ Analyst Code ต่อว่าผ่านมาตรฐานที่เรากำหนดไว้ร่วมกันหรือไม่ ถ้าผ่านค่อย Deploy ต่อไป เป็นต้น .. แค่คิดก็มันส์แล้ววว