SuperAPI AI Directory

dotnet-testing-test-naming-conventions

Testing & quality

View repository

Updated 10-15 23:45

About this skill

.NET Test Naming Convention Guide

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:

Original article

This skill content is distilled from the "Old-School Software Engineer's Testing Practice - 30-Day Challenge" series of articles:

Related skills

  • dotnet-testing-unit-test-fundamentals - Unit testing basics
  • dotnet-testing-xunit-project-setup - xUnit project setup