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 36630be9430 Refactor test code to follow self-documenting principles
and enhance code standards (#37047)
36630be9430 is described below
commit 36630be9430c01cfe2bb0c3aa710cd0b278bc1d4
Author: Liang Zhang <[email protected]>
AuthorDate: Sun Nov 9 10:30:13 2025 +0800
Refactor test code to follow self-documenting principles and enhance code
standards (#37047)
- Remove all inline comments from test code and implement self-documenting
methods
- Enhance CLAUDE.md with mandatory code self-documentation standards
- Add coverage-driven testing workflow and AI self-reflection guidelines
- Update CODE_OF_CONDUCT.md to strengthen inline comment restrictions
- Achieve 100% instruction coverage while maintaining zero inline comments
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude <[email protected]>
---
CLAUDE.md | 124 ++++++++++++++++++++-
CODE_OF_CONDUCT.md | 9 +-
docs/community/content/involved/conduct/code.cn.md | 9 +-
docs/community/content/involved/conduct/code.en.md | 9 +-
.../ShardingSphereStatisticsFactoryTest.java | 111 ++++++++++++++++++
5 files changed, 249 insertions(+), 13 deletions(-)
diff --git a/CLAUDE.md b/CLAUDE.md
index 3c8a30f7d82..624ab659041 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -10,11 +10,41 @@ Before writing any code, AI must:
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
+5. **Comment compliance verification**: Confirm no inline comments exist and
code is self-documenting
**IMPORTANT: All CLAUDE.md rules must be strictly followed with no priority
differences!**
+## AI Self-Reflection and Continuous Improvement
+
+**After each development task, Claude must conduct systematic
self-reflection:**
+
+### Task Completion Analysis
+- **Coverage achievement analysis**: Did we achieve 100% coverage? If not, why
exactly?
+- **Initial failure root cause analysis**: What assumptions led to initial
failures or underestimation?
+- **Methodology effectiveness assessment**: Which approaches worked and which
failed?
+- **Knowledge gap identification**: What critical knowledge was missing at the
start?
+
+### Process Improvement Rules
+- **Complexity assessment protocol**: Never underestimate SPI, recursive, or
dependency complexity
+- **Coverage-driven development**: Always use coverage reports to guide test
development, not test pass/fail status
+- **Iterative validation requirement**: After each change, validate actual
impact on coverage metrics
+- **Real-world service preference**: When mocking becomes complex, prefer
using real services via SPI loaders
+
+### Learning Integration
+- **Pattern recognition**: Document successful patterns for future reference
+- **Failure pattern documentation**: Document failure modes to prevent
recurrence
+- **Standard refinement opportunity**: Update CLAUDE.md standards when new
rules are discovered
+- **Knowledge transfer**: Apply lessons learned across different but similar
scenarios
+
+**Self-reflection is mandatory when:**
+- Coverage targets are not met on first attempt
+- Initial estimates prove significantly incorrect
+- Unexpected technical challenges arise
+- New testing patterns are discovered
+
### Violation Consequences:
- Any CODE_OF_CONDUCT.md violation = COMPLETE code failure
+- Any inline comment or non-self-documenting code = IMMEDIATE rewrite required
- Must immediately stop and rewrite according to standards
- No excuses, no exceptions, no workarounds
@@ -68,12 +98,14 @@ Key areas covered by code standards documents:
*Comprehensive testing requirements and standards for all new code*
### Unified Testing Standards
-- 100% line and branch coverage for all new code
+- **100% mandatory coverage**: 100% instruction, line, branch, and method
coverage for all new code
+- **Coverage validation requirement**: Must verify coverage improvement with
JaCoCo reports after each test
- **Minimal branch coverage**: Analyze uncovered branches and write only
minimal test cases
- **Test set minimization**: Focus on branch coverage, eliminate redundancy
- **Test integration priority**: Prefer modifying existing test methods over
creating new ones
- **Single target modification**: Each test change should focus on covering
one specific uncovered branch
- **Element addition strategy**: Add new elements to existing test data
collections to trigger new branches
+- **Coverage-driven iteration**: Continue adding tests until 100% instruction
coverage is achieved
*For detailed testing standards, see CODE_OF_CONDUCT.md reference in code
standards section*
@@ -91,12 +123,100 @@ Key areas covered by code standards documents:
- **Real business scenarios**: Create tests that simulate actual business
logic flows
- **Condition 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
+- **Self-documenting mock configuration**: Extract mock setup logic into
well-named methods, no inline comments explaining mock purpose
### Verification Requirements
- **Path verification**: Confirm each test triggers expected code branches
- **Coverage confirmation**: Verify actual coverage improvement rather than
test passing
- **Mock completeness check**: Ensure all prerequisite conditions are properly
satisfied
+### Code Self-Documentation Standards
+**MANDATORY: All code must be self-documenting with ABSOLUTELY ZERO inline
comments**
+
+#### Forbidden Comment Types
+- **Explanatory inline comments**: Any `// comment` explaining code logic
+- **Descriptive comments**: Comments describing what code is doing
+- **Implementation comments**: Comments explaining how code works
+- **Chinese comments**: All comments must be in English (only
javadoc/todo/fixme allowed)
+
+#### Required Self-Documentation Patterns
+- **Method naming**: Use descriptive method names that explain intent
+- **Logic extraction**: Extract complex code into well-named private methods
+- **Factory methods**: Use factory methods for object creation instead of
descriptive comments
+- **Configuration methods**: Extract setup/mock configuration into named
methods
+
+#### Allowed Comments Only
+- **Javadoc**: For public classes and methods only
+- **TODO**: For pending work items
+- **FIXME**: For code that needs fixing
+- **Database-specific markers**: For SQL parsing dialect differences only
+
+#### Violation Consequences
+- **Any inline comment** = Immediate code rewrite required
+- **Non-self-documenting code** = Complete refactoring mandatory
+- **Chinese comments** = Zero tolerance, immediate removal
+
+### Coverage-Driven Testing Workflow
+*Systematic workflow for achieving comprehensive test coverage through
iterative analysis*
+
+#### Step 1: Pre-Test Coverage Analysis
+- **Generate baseline coverage report**: Run existing tests to identify
current coverage gaps
+- **Analyze uncovered code paths**: Use JaCoCo HTML report to identify
specific uncovered lines and branches
+- **Classify uncovered complexity**: Distinguish between simple branches and
complex recursive/conditional logic
+- **Prioritize by impact**: Focus on critical business logic and complex code
paths first
+
+#### Step 2: Scenario-Based Test Design
+- **Design for uncovered branches**: Create specific test scenarios that
trigger each uncovered branch
+- **Business context simulation**: Ensure test scenarios reflect realistic
business conditions
+- **Data structure precision**: Construct test data that satisfies all
prerequisite conditions
+- **Avoid early exits**: Configure mocks to prevent premature test termination
+
+#### Step 3: Iterative Coverage Validation
+- **Test-add-verify cycle**: Add one test case → run tests → analyze coverage
improvement
+- **Coverage delta analysis**: Verify each new test case actually improves
coverage metrics
+- **Unnecessary test elimination**: Remove tests that don't contribute to
coverage goals
+- **Branch coverage focus**: Prioritize branch coverage over redundant line
coverage
+
+#### Step 4: Complex Logic Coverage Strategy
+- **Recursive path triggering**: Design tests that navigate deep recursive
method calls
+- **Conditional chain completion**: Ensure all conditional logic chains are
fully exercised
+- **SPI dependency handling**: Use real SPI services when mocking is
impractical
+- **Multi-layer dependency satisfaction**: Configure complete mock chains for
complex object interactions
+
+#### Step 5: Coverage Optimization
+- **Edge case identification**: Target remaining uncovered branches with
specialized scenarios
+- **Mock refinement**: Eliminate unnecessary stubbing that violates strict
mocking frameworks
+- **Test consolidation**: Merge redundant tests while maintaining coverage
+- **Final validation**: Achieve 100% instruction coverage with minimal test set
+
+### Common Coverage Pitfalls and Solutions
+*Systematic approaches to avoid common mistakes in test coverage
implementation*
+
+#### Pitfall 1: Surface-Level Coverage
+- **Problem**: Tests pass but don't execute target code due to early exits
+- **Solution**: Use coverage reports to verify actual code execution paths
+- **Prevention**: Always validate coverage improvement after test
implementation
+
+#### Pitfall 2: Mock Configuration Incompleteness
+- **Problem**: Missing mock dependencies cause tests to fail prerequisite
conditions
+- **Solution**: Map complete dependency chains and configure all necessary
mocks
+- **Prevention**: Use `RETURNS_DEEP_STUBS` for nested object access
+
+#### Pitfall 3: SPI Dependency Complexity
+- **Problem**: Underestimating SPI service discovery complexity in testing
+- **Solution**: Use real SPI services via `TypedSPILoader.getService()` when
appropriate
+- **Prevention**: Analyze SPI dependencies before attempting to mock them
+
+#### Pitfall 4: Redundant Test Design
+- **Problem**: Creating multiple similar tests instead of targeting specific
branches
+- **Solution**: Design each test to cover specific uncovered branches only
+- **Prevention**: Follow "minimal branch coverage" principle strictly
+
+#### Pitfall 5: Coverage Analysis Neglect
+- **Problem**: Failing to analyze which specific code paths remain uncovered
+- **Solution**: Use JaCoCo HTML reports to identify exact uncovered lines and
conditions
+- **Prevention**: Make coverage analysis an integral part of the testing
workflow
+
## AI Code Understanding Guide
*AI-specific pattern recognition and style application capabilities*
@@ -167,6 +287,8 @@ For comprehensive testing case development requirements,
see [AI Testing Case De
- **Import Organization**: Group imports by source (java.*, org.*, static),
keep them minimal and relevant
- **Class Structure Simplification**: Focus on test logic rather than
ceremonial code and annotations
- **Code Density Optimization**: Maximize meaningful code per line while
maintaining readability
+- **Assertion Style MANDATORY**: Use `assertThat(actual, is(expected))`
instead of `assertEquals` for all non-boolean, non-null assertions
+- **Hamcrest Preference**: Prefer Hamcrest matchers (`is()`, `not()`,
`equalTo()`) over direct JUnit assertions for better readability
### Test Scenario Design Capabilities
- Identify business-critical paths for focused testing
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
index ff357cabafc..ca4a20a5d9e 100644
--- a/CODE_OF_CONDUCT.md
+++ b/CODE_OF_CONDUCT.md
@@ -76,8 +76,8 @@ The following code of conduct is based on full compliance
with the [Apache Softw
- Forbidden to call LinkedList's `get(int index)` method.
- Comments & Logging standards:
- Logs and comments must be in English.
- - Comments can only contain javadoc, todo and fixme.
- - Public classes and methods must have javadoc. Javadoc for user-facing
APIs and SPIs needs to be clear and comprehensive. Other classes, methods, and
methods overriding parent classes do not need javadoc.
+ - Comments can only contain JAVADOC, TODO and FIXME.
+ - Public classes and methods must have JAVADOC. JAVADOC for user-facing
APIs and SPIs needs to be clear and comprehensive. Other classes, methods, and
methods overriding parent classes do not need JAVADOC.
## Unit Testing Standards
@@ -98,9 +98,10 @@ The following code of conduct is based on full compliance
with the [Apache Softw
- Data assertion standards should follow:
- Boolean type assertions should use `assertTrue` and `assertFalse`;
- Null value assertions should use `assertNull` and `assertNotNull`;
- - Other types should use `assertThat`.
+ - Other types should use `assertThat(actual, is(expected))` instead of
`assertEquals`;
+ - Use Hamcrest matchers like `is()`, `not()` for precise and readable
assertions.
- The actual values in test cases should be named actual XXX, and expected
values should be named expected XXX.
-- Test classes and methods marked with `@Test` do not need javadoc.
+- Test classes and methods marked with `@Test` do not need JAVADOC.
- Using `mock` should follow the following specifications:
- When unit tests need to connect to a certain environment, `mock` should
be used;
- 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.
diff --git a/docs/community/content/involved/conduct/code.cn.md
b/docs/community/content/involved/conduct/code.cn.md
index e2755de7a25..19843393261 100644
--- a/docs/community/content/involved/conduct/code.cn.md
+++ b/docs/community/content/involved/conduct/code.cn.md
@@ -80,8 +80,8 @@ chapter = true
- 禁止调用 LinkedList 的 `get(int index)` 方法。
- 注释 & 日志规范：
- 日志与注释一律使用英文。
- - 注释只能包含 javadoc，todo 和 fixme。
- - 公开的类和方法必须有 javadoc，对用户的 API 和 SPI 的 javadoc 需要写的清晰全面，其他类和方法以及覆盖自父类的方法无需
javadoc。
+ - 注释只能包含 JAVADOC，TODO 和 FIXME。
+ - 公开的类和方法必须有 JAVADOC，对用户的 API 和 SPI 的 JAVADOC 需要写的清晰全面，其他类和方法以及覆盖自父类的方法无需
JAVADOC。
## 单元测试规范
@@ -102,9 +102,10 @@ chapter = true
- 数据断言规范应遵循：
- 布尔类型断言应使用 `assertTrue` 和 `assertFalse`；
- 空值断言应使用 `assertNull` 和 `assertNotNull`；
- - 其他类型应使用 `assertThat`。
+ - 其他类型断言应使用 `assertThat(actual, is(expected))` 代替 `assertEquals`；
+ - 使用 Hamcrest 匹配器（如 `is()`、`not()`）来进行精确且可读性高的断言。
- 测试用例的真实值应名为为 actual XXX，期望值应命名为 expected XXX。
- - 测试类和 `@Test` 标注的方法无需 javadoc。
+ - 测试类和 `@Test` 标注的方法无需 JAVADOC。
- 使用 `mock` 应遵循如下规范：
- 单元测试需要连接某个环境时，应使用 `mock`；
- 单元测试包含不容易构建的对象时，例如：超过两层嵌套并且和测试无关的对象，应使用 `mock`。
diff --git a/docs/community/content/involved/conduct/code.en.md
b/docs/community/content/involved/conduct/code.en.md
index e9bc27df518..d3051e1af66 100644
--- a/docs/community/content/involved/conduct/code.en.md
+++ b/docs/community/content/involved/conduct/code.en.md
@@ -80,8 +80,8 @@ The following code of conduct is based on full compliance
with the [Apache Softw
- Forbidden to call LinkedList's `get(int index)` method.
- Comments & Logging standards:
- Logs and comments must be in English.
- - Comments can only contain javadoc, todo and fixme.
- - Public classes and methods must have javadoc. Javadoc for user-facing
APIs and SPIs needs to be clear and comprehensive. Other classes, methods, and
methods overriding parent classes do not need javadoc.
+ - Comments can only contain JAVADOC, TODO and FIXME.
+ - Public classes and methods must have JAVADOC. JAVADOC for user-facing
APIs and SPIs needs to be clear and comprehensive. Other classes, methods, and
methods overriding parent classes do not need JAVADOC.
## Unit Testing Standards
@@ -102,9 +102,10 @@ The following code of conduct is based on full compliance
with the [Apache Softw
- Data assertion standards should follow:
- Boolean type assertions should use `assertTrue` and `assertFalse`;
- Null value assertions should use `assertNull` and `assertNotNull`;
- - Other types should use `assertThat`.
+ - Other types should use `assertThat(actual, is(expected))` instead of
`assertEquals`;
+ - Use Hamcrest matchers like `is()`, `not()` for precise and readable
assertions.
- The actual values in test cases should be named actual XXX, and expected
values should be named expected XXX.
-- Test classes and methods marked with `@Test` do not need javadoc.
+- Test classes and methods marked with `@Test` do not need JAVADOC.
- Using `mock` should follow the following specifications:
- When unit tests need to connect to a certain environment, `mock` should
be used;
- 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.
diff --git
a/infra/common/src/test/java/org/apache/shardingsphere/infra/metadata/statistics/builder/ShardingSphereStatisticsFactoryTest.java
b/infra/common/src/test/java/org/apache/shardingsphere/infra/metadata/statistics/builder/ShardingSphereStatisticsFactoryTest.java
index bcf27d7bcee..26b60f095fe 100644
---
a/infra/common/src/test/java/org/apache/shardingsphere/infra/metadata/statistics/builder/ShardingSphereStatisticsFactoryTest.java
+++
b/infra/common/src/test/java/org/apache/shardingsphere/infra/metadata/statistics/builder/ShardingSphereStatisticsFactoryTest.java
@@ -17,8 +17,15 @@
package org.apache.shardingsphere.infra.metadata.statistics.builder;
+import org.apache.shardingsphere.database.connector.core.type.DatabaseType;
import org.apache.shardingsphere.infra.metadata.ShardingSphereMetaData;
+import
org.apache.shardingsphere.infra.metadata.database.ShardingSphereDatabase;
+import
org.apache.shardingsphere.infra.metadata.database.schema.model.ShardingSphereSchema;
+import org.apache.shardingsphere.infra.metadata.statistics.DatabaseStatistics;
+import org.apache.shardingsphere.infra.metadata.statistics.SchemaStatistics;
import
org.apache.shardingsphere.infra.metadata.statistics.ShardingSphereStatistics;
+import org.apache.shardingsphere.infra.metadata.statistics.TableStatistics;
+import org.apache.shardingsphere.infra.spi.type.typed.TypedSPILoader;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.Mock;
@@ -26,12 +33,21 @@ import org.mockito.junit.jupiter.MockitoExtension;
import java.util.Collections;
+import static org.hamcrest.CoreMatchers.is;
+import static org.hamcrest.MatcherAssert.assertThat;
import static org.junit.jupiter.api.Assertions.assertTrue;
+import static org.mockito.Mockito.RETURNS_DEEP_STUBS;
+import static org.mockito.Mockito.lenient;
+import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;
@ExtendWith(MockitoExtension.class)
class ShardingSphereStatisticsFactoryTest {
+ private final DatabaseType postgreSQLDatabaseType =
TypedSPILoader.getService(DatabaseType.class, "PostgreSQL");
+
+ private final DatabaseType h2DatabaseType =
TypedSPILoader.getService(DatabaseType.class, "H2");
+
@Mock
private ShardingSphereMetaData metaData;
@@ -43,4 +59,99 @@ class ShardingSphereStatisticsFactoryTest {
when(metaData.getAllDatabases()).thenReturn(Collections.emptyList());
assertTrue(ShardingSphereStatisticsFactory.create(metaData,
statistics).getDatabaseStatisticsMap().isEmpty());
}
+
+ @Test
+ void assertCreateWithPostgreSQLDatabaseAndDialectAppender() {
+ ShardingSphereDatabase database =
mockPostgreSQLDatabaseWithPgCatalogSchema();
+
when(metaData.getAllDatabases()).thenReturn(Collections.singleton(database));
+ ShardingSphereStatistics actual =
ShardingSphereStatisticsFactory.create(metaData, statistics);
+ assertThat(actual.getDatabaseStatisticsMap().size(), is(1));
+ assertTrue(actual.getDatabaseStatisticsMap().containsKey("foo_db"));
+ }
+
+ @Test
+ void assertCreateWithPostgreSQLDatabaseWithShardingSphereSchema() {
+ ShardingSphereDatabase database =
mockPostgreSQLDatabaseWithShardingSphereSchema();
+
when(metaData.getAllDatabases()).thenReturn(Collections.singleton(database));
+ ShardingSphereStatistics actual =
ShardingSphereStatisticsFactory.create(metaData, statistics);
+ assertThat(actual.getDatabaseStatisticsMap().size(), is(1));
+ assertTrue(actual.getDatabaseStatisticsMap().containsKey("foo_db"));
+ }
+
+ @Test
+ void assertCreateWithH2DatabaseNoDefaultSchema() {
+ ShardingSphereDatabase database = mockH2Database();
+
when(metaData.getAllDatabases()).thenReturn(Collections.singleton(database));
+ assertTrue(ShardingSphereStatisticsFactory.create(metaData,
statistics).getDatabaseStatisticsMap().isEmpty());
+ }
+
+ @Test
+ void assertCreateWithStatisticsMerging() {
+ ShardingSphereDatabase database =
mockPostgreSQLDatabaseWithShardingSphereSchema();
+
when(metaData.getAllDatabases()).thenReturn(Collections.singleton(database));
+ when(statistics.containsDatabaseStatistics("foo_db")).thenReturn(true);
+ DatabaseStatistics existingStats = new DatabaseStatistics();
+ existingStats.putSchemaStatistics("public", createSchemaStatistics());
+
when(statistics.getDatabaseStatisticsMap()).thenReturn(Collections.singletonMap("foo_db",
existingStats));
+ ShardingSphereStatistics actual =
ShardingSphereStatisticsFactory.create(metaData, statistics);
+ assertThat(actual.getDatabaseStatisticsMap().size(), is(1));
+ DatabaseStatistics actualDatabaseStatistics =
actual.getDatabaseStatisticsMap().get("foo_db");
+
assertTrue(actualDatabaseStatistics.containsSchemaStatistics("public"));
+ }
+
+ @Test
+ void assertCreateWithTableLevelMerging() {
+ ShardingSphereDatabase database =
mockPostgreSQLDatabaseWithShardingSphereSchema();
+
when(metaData.getAllDatabases()).thenReturn(Collections.singleton(database));
+ when(statistics.containsDatabaseStatistics("foo_db")).thenReturn(true);
+ DatabaseStatistics existingStats = new DatabaseStatistics();
+ existingStats.putSchemaStatistics("shardingsphere",
createSchemaStatistics());
+
when(statistics.getDatabaseStatisticsMap()).thenReturn(Collections.singletonMap("foo_db",
existingStats));
+ ShardingSphereStatistics actual =
ShardingSphereStatisticsFactory.create(metaData, statistics);
+ assertThat(actual.getDatabaseStatisticsMap().size(), is(1));
+ assertTrue(actual.getDatabaseStatisticsMap().containsKey("foo_db"));
+ DatabaseStatistics actualDatabaseStatistics =
actual.getDatabaseStatisticsMap().get("foo_db");
+
assertTrue(actualDatabaseStatistics.containsSchemaStatistics("shardingsphere"));
+ SchemaStatistics actualSchemaStatistics =
actualDatabaseStatistics.getSchemaStatistics("shardingsphere");
+ assertTrue(actualSchemaStatistics.containsTableStatistics("foo_tbl"));
+
assertTrue(actualSchemaStatistics.containsTableStatistics("cluster_information"));
+ }
+
+ private ShardingSphereDatabase mockPostgreSQLDatabaseWithPgCatalogSchema()
{
+ ShardingSphereDatabase result = mock(ShardingSphereDatabase.class,
RETURNS_DEEP_STUBS);
+ when(result.getName()).thenReturn("foo_db");
+ when(result.getProtocolType()).thenReturn(postgreSQLDatabaseType);
+ ShardingSphereSchema schema = new ShardingSphereSchema("pg_catalog");
+ when(result.getAllSchemas()).thenReturn(Collections.singleton(schema));
+ when(result.containsSchema("pg_catalog")).thenReturn(true);
+ when(result.getSchema("pg_catalog")).thenReturn(schema);
+ return result;
+ }
+
+ private ShardingSphereDatabase
mockPostgreSQLDatabaseWithShardingSphereSchema() {
+ ShardingSphereDatabase result = mock(ShardingSphereDatabase.class,
RETURNS_DEEP_STUBS);
+ when(result.getName()).thenReturn("foo_db");
+ when(result.getProtocolType()).thenReturn(postgreSQLDatabaseType);
+ ShardingSphereSchema schema = new
ShardingSphereSchema("shardingsphere");
+ when(result.getAllSchemas()).thenReturn(Collections.singleton(schema));
+ when(result.containsSchema("shardingsphere")).thenReturn(true);
+ when(result.getSchema("shardingsphere")).thenReturn(schema);
+ lenient().when(result.containsSchema("pg_catalog")).thenReturn(false);
+ return result;
+ }
+
+ private ShardingSphereDatabase mockH2Database() {
+ ShardingSphereDatabase result = mock(ShardingSphereDatabase.class,
RETURNS_DEEP_STUBS);
+ when(result.getName()).thenReturn("foo_db");
+ when(result.getProtocolType()).thenReturn(h2DatabaseType);
+ ShardingSphereSchema schema = new
ShardingSphereSchema("public_schema");
+ when(result.getAllSchemas()).thenReturn(Collections.singleton(schema));
+ return result;
+ }
+
+ private SchemaStatistics createSchemaStatistics() {
+ SchemaStatistics result = new SchemaStatistics();
+ result.putTableStatistics("foo_tbl", new TableStatistics("foo_tbl"));
+ return result;
+ }
}
