Test Method Naming Conventions
Standard Format
Use the three-part naming convention separated by underscores:
[被測試方法名稱]_[測試情境/輸入條件]_[預期行為/結果]
Explanation of Each Part
| Segment | Description | Example |
|---|---|---|
| Method under test name | The name of the method being tested | Add、ProcessOrder、IsValidEmail |
| Test scenario/input condition | Describes the preconditions or inputs of the test | 輸入1和2、輸入null、輸入有效訂單 |
| Expected behavior/result | Describes the expected output or behavior | 應回傳3、應拋出Exception、應回傳True |
Naming Example Comparison Table
Good Naming vs Bad Naming
The three-part naming convention can use Chinese or English, chosen according to team convention. The following shows both styles at the same time:
| Bad Naming | Chinese Naming (Recommended) | English Naming | Reason |
|---|---|---|---|
TestAdd |
Add_輸入1和2_應回傳3 |
Add_WhenGiven1And2_ShouldReturn3 |
Clearly states the test scenario and expected result |
Test1 |
Add_輸入負數和正數_應回傳正確結果 |
Add_WhenGivenNegativeAndPositive_ShouldReturnCorrectResult |
Meaningful description |
EmailTest |
IsValidEmail_輸入有效Email_應回傳True |
IsValidEmail_WhenValidEmail_ShouldReturnTrue |
Complete three-part naming |
OrderTest |
ProcessOrder_輸入null_應拋出ArgumentNullException |
ProcessOrder_WhenNull_ShouldThrowArgumentNullException |
Clear exception scenario |
Practical Examples
Basic Operation Tests
// ✅ 正常路徑測試
[Fact]
public void Add_輸入1和2_應回傳3()
// ✅ 邊界條件測試
[Fact]
public void Add_輸入0和0_應回傳0()
// ✅ 負數測試
[Fact]
public void Add_輸入負數和正數_應回傳正確結果()
Validation Logic Tests
// ✅ 有效輸入測試
[Fact]
public void IsValidEmail_輸入有效Email_應回傳True()
// ✅ 無效輸入 - null
[Fact]
public void IsValidEmail_輸入null值_應回傳False()
// ✅ 無效輸入 - 空字串
[Fact]
public void IsValidEmail_輸入空字串_應回傳False()
// ✅ 無效輸入 - 格式錯誤
[Fact]
public void IsValidEmail_輸入無效Email格式_應回傳False()
Business Logic Tests
// ✅ 處理流程測試
[Fact]
public void ProcessOrder_輸入有效訂單_應回傳處理後訂單()
// ✅ 例外處理測試
[Fact]
public void ProcessOrder_輸入null_應拋出ArgumentNullException()
// ✅ 格式化測試
[Fact]
public void GetOrderNumber_輸入有效訂單_應回傳格式化訂單號碼()
Calculation Logic Tests
// ✅ 正常計算
[Fact]
public void Calculate_輸入100元和10Percent折扣_應回傳90元()
// ✅ 無效輸入 - 負數
[Fact]
public void Calculate_輸入負數價格_應拋出ArgumentException()
// ✅ 邊界值測試
[Fact]
public void Calculate_輸入0元價格_應正常處理()
// ✅ 含稅計算
[Fact]
public void CalculateWithTax_輸入100元和5Percent稅率_應回傳105元()
State Change Tests
// ✅ 初始狀態測試
[Fact]
public void Increment_從0開始_應回傳1()
// ✅ 連續操作測試
[Fact]
public void Increment_從0開始連續兩次_應回傳2()
// ✅ 重設測試
[Fact]
public void Reset_從任意值_應回傳0()
Test Class Naming Conventions
Standard Format
[被測試類別名稱]Tests
Example
| Class under test | Test class name |
|---|---|
Calculator |
CalculatorTests |
OrderService |
OrderServiceTests |
EmailHelper |
EmailHelperTests |
PriceCalculator |
PriceCalculatorTests |
Class Structure Template
namespace MyProject.Tests;
/// <summary>
/// class CalculatorTests - Calculator 測試類別
/// </summary>
public class CalculatorTests
{
private readonly Calculator _calculator;
public CalculatorTests()
{
_calculator = new Calculator();
}
//---------------------------------------------------------------------------------------------
// Add 方法測試
[Fact]
public void Add_輸入1和2_應回傳3()
{
// ...
}
//---------------------------------------------------------------------------------------------
// Divide 方法測試
[Fact]
public void Divide_輸入10和2_應回傳5()
{
// ...
}
}
Parameterized Test Naming
When using [Theory] , the naming conventions are:
// ✅ 使用「各種」表示多組測試資料
[Theory]
[InlineData(1, 2, 3)]
[InlineData(-1, 1, 0)]
[InlineData(0, 0, 0)]
public void Add_輸入各種數值組合_應回傳正確結果(int a, int b, int expected)
// ✅ 使用「有效」表示正向測試
[Theory]
[InlineData("test@example.com")]
[InlineData("user.name@domain.org")]
public void IsValidEmail_輸入有效Email格式_應回傳True(string validEmail)
// ✅ 使用「無效」表示負向測試
[Theory]
[InlineData("invalid-email")]
[InlineData("@example.com")]
public void IsValidEmail_輸入無效Email格式_應回傳False(string invalidEmail)
Common Scenario Vocabulary
Input Condition Vocabulary
| Vocabulary | Usage Scenario |
|---|---|
輸入 |
General input parameters |
給定 |
Given-When-Then style |
當 |
Event trigger |
從...開始 |
Initial state description |
Expected Result Vocabulary
| Vocabulary | Usage Scenario |
|---|---|
應回傳 |
Has return value |
應拋出 |
Expected exception |
應為 |
State verification |
應包含 |
Collection verification |
應正常處理 |
Boundary condition |
Naming Checklist
When naming test methods, please confirm:
- Use three-part naming
方法_情境_預期 - Scenario description is clear and specific
- Expected result is concrete and verifiable
- Use Chinese to increase readability
- Avoid vague terms such as
Test1、TestMethod - Parameterized tests use terms such as "various", "valid", "invalid", etc.
Test Report Readability
Good naming makes test reports easier to read:
PASS CalculatorTests
PASS Add_輸入1和2_應回傳3
PASS Add_輸入負數和正數_應回傳正確結果
FAIL Divide_輸入10和0_應拋出DivideByZeroException
PASS EmailHelperTests
PASS IsValidEmail_輸入有效Email_應回傳True
PASS IsValidEmail_輸入null值_應回傳False
Output Format
- Use the three-part naming convention:
[方法名稱]_[測試情境]_[預期行為] - Test classes are named
{被測類別}Tests - Scenario descriptions use Chinese to improve readability
- Parameterized tests use terms such as "various", "valid", "invalid", etc.
Reference Resources
Please refer to the example files in the same directory:
- templates/naming-convention-examples.cs - Complete example of naming conventions
Original article
This skill content is distilled from the "Old-School Software Engineer's Testing Practice - 30-Day Challenge" series of articles:
- Day 01 - An Old-School Engineer's Testing Epiphany
- Ironman series article:https://ithelp.ithome.com.tw/articles/10373888
- Sample code:https://github.com/kevintsengtw/30Days_in_Testing_Samples/tree/main/day01
Related skills
dotnet-testing-unit-test-fundamentals- Unit testing basicsdotnet-testing-xunit-project-setup- xUnit project setup