Test-Driven Development for OpenMetadata
SkillWeb & browsingThe tdd skill is a test-driven development guide for an AI agent working in OpenMetadata. It enforces the RED-GREEN-REFACTOR cycle: write a small failing test, add the minimum code to pass it, then clean up while keeping tests green. It covers Java with JUnit, Python with pytest, and TypeScript with Jest or Playwright, and it explains where tests live and which runner to use per layer.
Then ask your AI: use the Test-Driven Development for OpenMetadata skill
Details
Instructions available. Your AI can read the instructions. Execution depends on the setup they require.
Account requirements not reviewed. Check the skill instructions before use; Ahel provides instructions and does not run this skill.
No other account needed.
Have an OpenMetadata checkout with the Java, Python, and TypeScript toolchains available.
What your AI can do with it
- Guides the RED-GREEN-REFACTOR cycle for new features and bug fixes
- Covers Java (JUnit), Python (pytest), and TypeScript (Jest/Playwright)
- Points to test locations and runners for each layer
- Warns against anti-patterns like mocking everything
- Keeps tests focused on observable outcomes, not implementation details
Getting started
- Have an OpenMetadata checkout with the Java, Python, and TypeScript toolchains available.
- Add the tdd skill to your agent so it can follow the RED-GREEN-REFACTOR cycle.
- Describe the feature or bug you want to work on, and let the agent write the first failing test.
- Run the test with the runner for that layer, such as mvn test, pytest, or yarn test, and confirm it fails.
- Add the minimum code to pass, then refactor while keeping the suite green.
What this skill tells your AI
The instructions your AI receives, as published by open-metadata/openmetadata in skills/tdd/SKILL.md and read by Ahel’s review.
Enforce RED-GREEN-REFACTOR discipline across all three language stacks.
When to Use
- Implementing any new feature or behavior
- Fixing bugs (write a test that reproduces the bug first)
- Adding new API endpoints, connectors, or UI components
The Cycle
1. RED - Write a Failing Test
Write the smallest test that describes the desired behavior. Run it. It must fail. If it passes, your test isn't testing the new behavior.
Java (JUnit 5):
# Write test in openmetadata-service/src/test/ or openmetadata-integration-tests/
mvn test -pl openmetadata-service -Dtest=YourTestClass#yourTestMethod
Python (pytest):
source env/bin/activate
cd ingestion
# Write test using pytest style — plain assert, no unittest.TestCase
python -m pytest tests/unit/your_test.py::test_your_function -v
TypeScript (Jest):
cd openmetadata-ui/src/main/resources/ui
yarn test path/to/YourComponent.test.ts
Rules for RED:
- Test one behavior per test
- Use descriptive test names that explain what should happen
- Assert on observable outcomes (API responses, database state, rendered output), not internal method calls
- For Python: use
assert x == y, notself.assertEqual(x, y)
2. GREEN - Write the Minimum Code to Pass
Write only the code needed to make the test pass. No more.
- Don't add error handling for cases you haven't tested
- Don't generalize — hardcode if that's what the test requires
- Don't clean up or refactor yet
Run the test again. It must pass.
3. REFACTOR - Clean Up While Green
Now improve the code while keeping tests green:
- Remove duplication
- Improve naming
- Extract methods if needed (but don't over-abstract)
- Run the full test suite for the module to check for regressions
# Java — format then test
mvn spotless:apply
mvn test -pl openmetadata-service
# Python — format, lint, then test
cd ingestion && make py_format && make py_format_check
python -m pytest tests/unit/your_test.py -v
# TypeScript — lint then test
cd openmetadata-ui/src/main/resources/ui
yarn lint:fix
yarn test path/to/YourComponent.test.ts
4. Repeat
Go back to RED with the next behavior. Each cycle should take minutes, not hours.
What to Test Where
| Layer | Test Type | Location | Runner |
|---|---|---|---|
| Java REST API | Integration | openmetadata-integration-tests/ | mvn verify |
| Java service logic | Unit | openmetadata-service/src/test/ | mvn test |
| Python connectors | Unit | ingestion/tests/unit/ | pytest |
| Python integration | Integration | ingestion/tests/integration/ | pytest |
| React components | Unit | Co-located .test.ts files | yarn test |
| UI E2E flows | E2E | playwright/e2e/ | yarn playwright:run |
Anti-Patterns to Avoid
- Writing code before the test. If you catch yourself doing this, stop. Write the test first.
- Mocking everything. Mock external boundaries (HTTP clients, third-party APIs), not your own classes. If you need 3+ mocks, write an integration test instead.
- Testing implementation details. Don't assert on internal method calls with
verify(). Assert on outcomes. - Giant test methods. Each test should verify one behavior. Split multi-assertion tests into separate test cases.
- Skipping REFACTOR. The refactor step is where code quality happens. Don't skip it.
OpenMetadata-Specific Patterns
Java integration tests use BaseEntityIT with TestNamespace for isolation and OpenMetadataClient for API calls. Prefer this over heavily mocked unit tests for API testing.
Python connector tests should test real behavior:
# Good: test the actual parsing logic
def test_parse_table_metadata():
raw = {"name": "users", "columns": [...]}
result = parse_table(raw)
assert result.name == "users"
assert len(result.columns) == 3
# Bad: mock everything and verify calls
def test_parse_table_metadata():
mock_client = MagicMock()
mock_client.get.return_value = {...}
# ... 20 lines of mock setup
verify(mock_client.get).called_once() # proves nothing
Frontend tests should render components and assert on visible output:
// Good: test what the user sees
render(<MyComponent data={testData} />);
expect(screen.getByText('Expected Label')).toBeInTheDocument();
// Bad: test implementation details
expect(component.state.internalFlag).toBe(true);
Signals
- GitHub stars
- 15k
- Forks
- 2k
- Last commit
- Oct 2026
Questions
- What is TDD with an example?
- TDD means writing a failing test first, then the minimum code to pass it, then cleaning up. For example, write a pytest that asserts a new API returns 200, watch it fail, add the endpoint, then refactor.
- Which languages and test runners does this skill cover?
- It covers Java with JUnit, Python with pytest, and TypeScript with Jest or Playwright.
Advanced
- Item type
- skill
- Key
tdd-open-metadata- Source
- github.com/open-metadata/openmetadata
github.com/open-metadata/openmetadata
Related picks
Skill · a5c-ai
The pick for Java110-java-maven-best-practices
Skill · jabrena
The pick for Javadbos-python
Skill · sickn33
The pick for Pythonpython-design-patterns
Skill · wshobson
The pick for Pythonsetup-ts-deep-modules
Skill · mattpocock
The pick for TypeScripttypescript-providers
Skill · composiohq
The pick for TypeScript