測試程式碼是軟體開發最重要的方面之一，因為它可以確保產品的品質、可擴展性和可靠性。
但是，如果沒有任何指導，編寫有效的測試可能會很困難。測試程式碼可能比實際功能的程式碼更複雜、更難維護！
原文出處：https://dev.to/one-beyond/the-5-principles-of-unit-testing-1p5f
1.精簡和準確的測試
測試程式碼必須簡單且易於使用。任何查看測試的人都應該立即知道測試的內容及其目的是什麼。開發測試應該以很少的精力和時間投入帶來巨大的價值。
您是否需要超過 30 秒的時間來閱讀和理解您的測試？重寫它！
測試“覆蓋率”是重點嗎？不！ 僅測試必要的部份就好。為了敏捷性和簡單性，最好放棄一些測試，只測試主要業務邏輯和主要邊緣情況就好。
2.測試行為，而不是元件實作
不要檢查程式碼中的每一行和內部變數。測試時，您應該專注於結果。即使方法內的程式碼被重構，結果也應該永遠保持不變！
這樣，如果程式碼庫發生更改，您不需要重寫測試。
// Wrong ❌ - Test behaviour
describe('Evaluation Service', () => {
describe('Register Students', () => {
it('Should add new students to the evaluation service', () => {
const studentJosh = {
id: 1,
name: 'Josh McLovin',
average: 6.98,
}
evaluationService.addStudent(studentJosh)
expect(evaluationService._students[0].name).toBe('Josh')
expect(evaluationService._students[0].average).toBe(6.98)
})
})
})
// Right ✅ - Test behaviour
describe('Evaluation Service', () => {
describe('Register Students', () => {
it('Should add new students to the evaluation service', () => {
const studentJosh = {
id: 1,
name: 'Josh McLovin',
average: 6.98,
}
evaluationService.addStudent(studentJosh)
expect(evaluationService.getStudentAverage('Josh')).toBe(6.98)
})
})
})
3. 關於命名和結構：AAA 模式
您是否曾經遇到過名為“它應該[...]正確”的失敗測試，但花了幾分鐘才找到問題所在？
良好命名和結構可以讓您快速且準確地找到任何失敗的測試，最終節省您的寶貴時間。因此，讓我們深入探討兩個關鍵原則，以便在下次測試時牢記：
3.1 經過深思熟慮的測試命名：
在命名您的測試時，請嘗試合併以下資訊：
- 正在測試什麼？
- 什麼情況？
- 預期結果是什麼？
// Right ✅ - Test naming
// 1. What is being tested:
describe('Evaluation Service', () => {
describe('Evaluate Students', () => {
// 2 & 3. Context and expected result
it('If the student grade is below the minimum grade, student should be suspended', () => {
const students = [
{ name: 'Mark', grade: 4.25 },
{ name: 'Colin', grade: 6.7 },
{ name: 'Ben', grade: 5.3 },
]
const result = evaluationService.evaluateStudents({ students, minGrade: 5 })
expect(result['Mark']).toBe('suspended')
})
})
})
3.2 測試程式碼結構的AAA模式：
如果您想維護一個可讀且易於理解的測試套件，請按如下方式建立測試：
安排：設定模擬所需情況所需的所有程式碼。這可以包括初始化變數、模擬響應、實例化被測單元等。
行為：執行正在測試的內容，通常在一行程式碼中。
斷言：檢查得到的結果是否為預期的結果。與上面的一樣，這應該只需要一行。
// Right - AAA Testing Pattern
describe('Evaluation Service', () => {
describe('Average Calculation', () => {
it('Should calculate the average grade of all the students', () => {
// Arrange: create an object with the student names and their grades
const students = [
{ name: 'Mark', grade: 4 },
{ name: 'Colin', grade: 10 },
{ name: 'Ben', grade: 7 },
{ name: 'Tim', grade: 3 },
]
// Act: execute the getAverage method
const avg = evaluationService.getAverage(students)
// Assert: check if the result is the expected one -> (4+10+7+3)/4 = 6
expect(avg).toEqual(6)
})
})
})
4。確定性和隔離測試
如果一個失敗的測試使您的整個套件變紅，那麼您可能沒有以正確的方式處理它！
測試應該獨立和隔離，一次針對並處理一個特定邏輯，從而完成更快、更穩定的測試套件。
如果您不獨立編寫測試會發生什麼？
您將無法找出錯誤和問題的確切原因和位置。
重構測試時，您必須更新和同步多個測試。
您將無法以任何順序執行測試，這可能會導致破壞或跳過某些斷言或期望。
5。基於屬性的測試和真實資料
厭倦了在測試中編寫大量可能的輸入？基於屬性的測試可以為您做到這一點！……那是什麼？
基於屬性的測試建立了數百種可能的組合，強調了測試並增加了發現以前未被注意到的錯誤的機會。這種方法甚至可以傳回可能導致意外結果的輸入。
JSVerify 或 Fast-Check 等函式庫提供了促進基於屬性的測試的基本工具。
但是，如果您不想深入進行如此廣泛的測試，那麼盡可能利用真實資料至關重要。像“abc”或“1234”這樣的輸入可能會在實際失敗時錯誤地通過測試。
// Wrong ❌ - False Positive - Test that passes even though it shouldn't
class EvaluationService {
_students = [];
addStudent(student) {
// Add the student if the name has no numbers
if(!student.name.matches(/^([^0-9]*)$/)){
this._students.push(student);
}
}
}
describe('Evaluation Service', () => {
describe('Register Students', () => {
it('Should add students to the Evaluation service', () => {
const mockStudent = {
id: 2,
name: 'username',
average: 7
}
// Won't fail because the name is a string without number -> We are not checking what happens if the user
// inputs a name with a number.
evaluationService.addStudent(mockStudent)
expect(evaluationService.getStudentAverage('username')).toBe(7)
})
})
})
// In the example above, we are making a test so the test passes, instead of looking for edge cases with realistic data
額外提示！
如果您在測試元件中的任何邏輯時遇到困難，這可能反映出您也許應該將元件邏輯分解為更小、更容易且可測試的程式碼片段！
總而言之，遵循此最佳實踐可能會帶來一種新的、可讀且可維護的方法來測試您喜愛的生產程式碼。
經過測試的應用程式才是可靠的應用程式！
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
