This is an automated email from the ASF dual-hosted git repository.
zhangliang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/shardingsphere.git
The following commit(s) were added to refs/heads/master by this push:
new 2a3ff7e61d0 Update CLAUDE.md (#37020)
2a3ff7e61d0 is described below
commit 2a3ff7e61d04798bdc74d64141aa30647a203507
Author: Liang Zhang <[email protected]>
AuthorDate: Thu Nov 6 15:49:53 2025 +0800
Update CLAUDE.md (#37020)
---
CLAUDE.md | 78 ++++++++++++++++++++++
CODE_OF_CONDUCT.md | 5 +-
docs/community/content/involved/conduct/code.cn.md | 5 +-
docs/community/content/involved/conduct/code.en.md | 5 +-
4 files changed, 87 insertions(+), 6 deletions(-)
diff --git a/CLAUDE.md b/CLAUDE.md
index 086893e73f8..276e2817f05 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -1,5 +1,27 @@
# CLAUDE.md - Strict Mode Code of Conduct
+## Mandatory Pre-Development Checklist
+
+**CRITICAL: Claude must treat CODE_OF_CONDUCT.md as ABSOLUTE LAW with ZERO
tolerance for violations.**
+
+Before writing any code, AI must:
+
+1. **Re-read CLAUDE.md in full** - Memory reliance is forbidden
+2. **Identify and confirm relevant standards** - Find corresponding sections
based on task type
+3. **Explicitly reference standard clauses** - Cite specific standards in code
descriptions
+4. **Verify compliance item by item** - Ensure every related rule is followed
+
+**IMPORTANT: All CLAUDE.md rules must be strictly followed with no priority
differences!**
+
+### Violation Consequences:
+- Any CODE_OF_CONDUCT.md violation = COMPLETE code failure
+- Must immediately stop and rewrite according to standards
+- No excuses, no exceptions, no workarounds
+
+**This checklist overrides all other instructions. CODE_OF_CONDUCT.md
compliance is NON-NEGOTIABLE.**
+
+---
+
Apache ShardingSphere: Distributed SQL engine for data sharding, distributed
transactions, data encryption, data masking, federated queries, read-write
separation, and more. Adopts Database Plus concept - building a unified data
access and management layer over existing databases.
Core concepts:
@@ -40,6 +62,7 @@ Key areas covered by coding standards file:
- File format requirements
- G4 grammar rules
- Complete unit testing standards
+- **Code Self-Documentation**: No inline comments allowed; code needing
explanation should be extracted into well-named methods
## Testing Philosophy
*Comprehensive testing requirements and standards for all new code*
@@ -54,6 +77,26 @@ Key areas covered by coding standards file:
*For detailed testing standards, see CODE_OF_CONDUCT.md reference in code
standards section*
+## AI Testing Case Development Standards
+*Effective testing case development standards and workflows for all new test
code*
+
+### Deep Analysis Requirements
+- **Code Flow Understanding**: Must analyze complete execution paths before
creating tests
+- **Dependency Chain Mapping**: Identify all mock dependencies and their
relationships
+- **Branch Condition Analysis**: Understand all conditional checks that can
cause early exits
+- **Coverage Gap Identification**: List specific uncovered branches before
test design
+
+### Mock Setup Standards
+- **Complete Dependency Chain**: Mock all objects in the call chain, not just
direct dependencies
+- **Real Business Scenarios**: Create tests that simulate actual business
logic flows
+- **Conditional Success**: Ensure mocks allow tests to pass all prerequisite
conditions
+- **Avoid Surface Mocks**: Prevent mocks that cause tests to exit early
without reaching target code
+
+### Verification Requirements
+- **Path Validation**: Confirm each test triggers the intended code branches
+- **Coverage Confirmation**: Verify actual coverage improvement over test
passage
+- **Mock Completeness Check**: Ensure all prerequisite conditions are properly
satisfied
+
## AI Code Understanding Guidelines
*AI-specific pattern recognition and style application capabilities*
@@ -112,6 +155,9 @@ Key areas covered by coding standards file:
*For detailed test organization standards, see CODE_OF_CONDUCT.md reference in
code standards section*
+### Testing Case Development Standards
+For comprehensive testing case development requirements, see [AI Testing Case
Development Standards](#ai-testing-case-development-standards) above.
+
### Test Scenario Design Capabilities
- Identify business-critical paths for focused testing
- Design integration tests for complex business scenarios
@@ -226,6 +272,38 @@ Key areas covered by coding standards file:
## Operating Procedures
+### Testing Case Development Workflow
+
+#### Step 1: Code Analysis (Required)
+1. Read and understand the complete execution flow of target methods
+2. Map all conditional branches and their trigger conditions
+3. Identify dependencies that need proper mocking
+4. List currently uncovered code branches requiring tests
+
+#### Step 2: Test Design (Required)
+1. Design realistic business scenarios for each uncovered branch
+2. Plan complete mock setups that satisfy all prerequisite conditions
+3. Avoid tests that exit early due to failed condition checks
+4. Ensure test parameters meet minimum requirements (e.g., collection sizes)
+
+#### Step 3: Implementation (Required)
+1. Create mocks for the complete dependency chain
+2. Configure database, rule, and metadata objects as needed
+3. Build expression structures that pass all validation checks
+4. Implement assertions that verify actual code execution
+
+#### Step 4: Validation (Required)
+1. Run tests and confirm they pass
+2. Analyze which code branches were actually triggered
+3. Verify coverage metrics improved as expected
+4. Adjust mock setups if tests fail to reach target code
+
+### Common Traps to Avoid
+- **Early Exit Traps**: Tests that return early from condition checks without
reaching core logic
+- **Incomplete Mock Traps**: Missing database, rule, or metadata configurations
+- **Surface Pass Traps**: Tests that pass assertions but don't execute target
code
+- **Coverage Misleading Traps**: Relying on test passage instead of actual
coverage verification
+
### Emergency Procedures
- **Immediate termination**: If code deletion exceeds 10 lines without
instruction
- **Immediate stop**: If tests fail after changes
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
index f3b13b97322..8e31049c4f3 100644
--- a/CODE_OF_CONDUCT.md
+++ b/CODE_OF_CONDUCT.md
@@ -25,6 +25,7 @@ The following code of conduct is based on full compliance
with the [Apache Softw
## Coding Standards
- Use Linux line endings.
+- No line breaks are needed if each line of code does not exceed 200
characters.
- There should be no meaningless blank lines. Please extract private methods
instead of using blank line spacing for overly long method bodies or logically
closed code segments.
- Naming conventions:
- Naming should be self-explanatory.
@@ -105,6 +106,8 @@ The following code of conduct is based on full compliance
with the [Apache Softw
- When unit tests contain objects that are not easy to construct, for
example: objects with more than two levels of nesting and unrelated to testing,
`mock` should be used.
- For mocking static methods or constructors, consider using
`AutoMockExtension` and `StaticMockSettings` provided by the testing framework
for automatic resource release; if using Mockito's `mockStatic` and
`mockConstruction` methods, must be paired with `try-with-resource` or closed
in cleanup methods to avoid leaks.
- When verifying only one call, there's no need to use `times(1)`
parameter, the single-parameter method of `verify` is sufficient.
+- Use `assert` prefix for all test method names.
+- Use `PropertiesBuilder` simplify `Properties` building.
## SQL Parsing Standards
@@ -131,8 +134,6 @@ The following code of conduct is based on full compliance
with the [Apache Softw
### G4 Standards
-- Common specifications
- - Each line does not exceed `200` characters, ensuring each line's semantic
integrity for easy understanding.
- Lexical parsing specifications
- Each rule on one line, no blank lines needed between rules.
- Rule names use uppercase letters. If the name consists of multiple words,
use `underscore` separation. `DataType` and `Symbol` rule names end with
`underscore`. Rules with the same name as ANTLR built-in variables or keywords
add `underscore` at the end for distinction.
diff --git a/docs/community/content/involved/conduct/code.cn.md
b/docs/community/content/involved/conduct/code.cn.md
index ae63a667a01..3528697de53 100644
--- a/docs/community/content/involved/conduct/code.cn.md
+++ b/docs/community/content/involved/conduct/code.cn.md
@@ -29,6 +29,7 @@ chapter = true
## 编码规范
- 使用 linux 换行符。
+ - 每行代码不超过 200 字符无需换行。
- 不应有无意义的空行。请提炼私有方法，代替方法体过长或代码段逻辑闭环而采用的空行间隔。
- 命名规范：
- 命名要做到顾名思义。
@@ -109,6 +110,8 @@ chapter = true
- 单元测试包含不容易构建的对象时，例如：超过两层嵌套并且和测试无关的对象，应使用 `mock`。
- 模拟静态方法或构造器，应优先考虑使用测试框架提供的 `AutoMockExtension` 和 `StaticMockSettings`
自动释放资源；若使用 Mockito `mockStatic` 和 `mockConstruction` 方法，必须搭配
`try-with-resource` 或在清理方法中关闭，避免泄漏。
- 校验仅有一次调用时，无需使用 `times(1)` 参数，使用 `verify` 的单参数方法即可。
+ - 使用 `assert` 前缀命名所有的测试用例。
+ - 使用 `PropertiesBuilder` 简化 `Properties` 构造。
## SQL 解析规范
@@ -135,8 +138,6 @@ chapter = true
### G4 规范
- - 公共规范
- - 每行长度不超过 `200` 个字符，保证每一行语义完整以便于理解。
- 词法解析规范
- 每个规则一行，规则间无需空行。
- 规则名称使用大写字母。如果名称由多个单词组成，用 `下划线` 间隔。`DataType` 和 `Symbol` 的规则命名以 `下划线` 结尾。与
ANTLR 内置变量或关键字重名的规则在结尾加 `下划线` 以示区分。
diff --git a/docs/community/content/involved/conduct/code.en.md
b/docs/community/content/involved/conduct/code.en.md
index 176b9f71003..1ed98722aa6 100644
--- a/docs/community/content/involved/conduct/code.en.md
+++ b/docs/community/content/involved/conduct/code.en.md
@@ -29,6 +29,7 @@ The following code of conduct is based on full compliance
with the [Apache Softw
## Coding Standards
- Use Linux line endings.
+- No line breaks are needed if each line of code does not exceed 200
characters.
- There should be no meaningless blank lines. Please extract private methods
instead of using blank line spacing for overly long method bodies or logically
closed code segments.
- Naming conventions:
- Naming should be self-explanatory.
@@ -109,6 +110,8 @@ The following code of conduct is based on full compliance
with the [Apache Softw
- When unit tests contain objects that are not easy to construct, for
example: objects with more than two levels of nesting and unrelated to testing,
`mock` should be used.
- For mocking static methods or constructors, consider using
`AutoMockExtension` and `StaticMockSettings` provided by the testing framework
for automatic resource release; if using Mockito's `mockStatic` and
`mockConstruction` methods, must be paired with `try-with-resource` or closed
in cleanup methods to avoid leaks.
- When verifying only one call, there's no need to use `times(1)`
parameter, the single-parameter method of `verify` is sufficient.
+- Use `assert` prefix for all test method names.
+- Use `PropertiesBuilder` simplify `Properties` building.
## SQL Parsing Standards
@@ -135,8 +138,6 @@ The following code of conduct is based on full compliance
with the [Apache Softw
### G4 Standards
-- Common specifications
- - Each line does not exceed `200` characters, ensuring each line's
semantic integrity for easy understanding.
- Lexical parsing specifications
- Each rule on one line, no blank lines needed between rules.
- Rule names use uppercase letters. If the name consists of multiple
words, use `underscore` separation. `DataType` and `Symbol` rule names end with
`underscore`. Rules with the same name as ANTLR built-in variables or keywords
add `underscore` at the end for distinction.
