Provides a structured approach to running and validating unit tests within the cdflib codebase.
Install
mkdir -p .claude/skills/unit-test-workflow && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/15105" && unzip -o skill.zip -d .claude/skills/unit-test-workflow && rm skill.zipInstalls to .claude/skills/unit-test-workflow
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Run and validate cdflib unit tests after code changes. Use when editing Python code, verifying regressions, or preparing a PR. Covers default local pytest runs, optional remote-data tests, and failure triage.Key capabilities
- →Run default local unit tests using `pytest`
- →Run remote-data dependent tests using `pytest -m remote_data`
- →Interpret test results to identify failures and tracebacks
- →Triage failing tests to determine cause (new change vs. pre-existing)
- →Fix code or tests as appropriate to resolve failures
- →Report completion of testing cycle with scope and results
How it works
The skill outlines a workflow for running `cdflib` unit tests, differentiating between fast local tests and slower remote-data tests, and provides steps for interpreting results, triaging failures, and reporting completion.
Inputs & outputs
When to use unit-test-workflow
- →Running unit tests after code modifications
- →Validating fixes for regression bugs
- →Preparing a codebase for a pull request
About this skill
cdflib Unit Test Workflow
What This Skill Produces
- A repeatable test workflow after code changes.
- A clear choice between quick local validation and slower remote-data validation.
- A pass/fail decision with explicit completion checks.
When to Use
- After modifying code under
cdflib/. - Before opening or updating a pull request.
- When investigating possible regressions in parsing, writing, epochs, or xarray behavior.
Repository Test Model
- Unit tests live in
tests/. - Default local validation command is:
pytest
- In this repository, the default
pytestrun is the normal fast path and does not run the remote-data suite. - Remote-data tests depend on downloading sample files and are slower (~15 minutes).
- Remote-data coverage is also exercised by CI on a weekly schedule (Monday 06:00 UTC) in
.github/workflows/remote-tests.yaml.
Procedure
1. Choose Test Scope
- If code changes are functional (logic, parsing, writing, time conversion, xarray integration), run full local tests with
pytest. - If the change is docs-only or non-runtime metadata, tests may be optional unless requested by maintainers.
- If code touches behavior known to depend on external sample data, include remote-data validation when practical.
2. Run Default Local Suite
Use:
pytest
Expected outcome:
- Exit code 0.
- No new failures introduced by the change.
3. Branch for Remote-Data Validation (Optional/Deeper)
Use this branch when changes affect data-read compatibility across real-world files or when maintainers request deeper confidence.
Recommended command path from project docs:
pytest -m remote_data
Alternative CI-style invocation:
pytest --remote-data
4. Interpret Results and Act
- If tests pass: report completion and summarize what scope was run.
- If tests fail:
- Identify first failing test and traceback.
- Determine whether failure is caused by the new changes or a pre-existing issue.
- Fix code/tests as appropriate.
- Re-run
pytestuntil green.
5. Completion Checks
A testing cycle is complete when all of the following are true:
- The intended test scope was run (default local suite at minimum).
pytestpassed for that scope.- Any failures encountered were triaged and addressed.
- The final summary states exactly which command(s) were run.
Quick Decision Table
| Situation | Command | Notes |
|---|---|---|
| Standard code change | pytest | Default, expected for most edits |
| Suspected remote-data impact | pytest -m remote_data or pytest --remote-data | Slower, network-dependent |
| Pre-merge confidence check | pytest (+ remote-data when relevant) | Match change risk to test depth |
Agent Output Format
When using this skill, report:
- What changed.
- Which test command(s) were run.
- Whether tests passed.
- If failures occurred, what was fixed and what re-runs succeeded.
When not to use it
- →When code changes are docs-only or non-runtime metadata and not requested by maintainers
- →When the task is not related to `cdflib` unit testing
- →When a repeatable test workflow is not desired
Limitations
- →Unit tests live in `tests/` directory
- →Remote-data tests depend on downloading sample files
- →Remote-data coverage is also exercised by CI on a weekly schedule
How it compares
This skill provides a specific, structured workflow for testing `cdflib` code changes, including guidance on test scope selection and failure triage, which is more directed than general `pytest` usage.
Compared to similar skills
unit-test-workflow side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| unit-test-workflow (this skill) | 0 | 4mo | Review | Beginner |
| mflux-pr | 1 | 2mo | Review | Advanced |
| python-testing-patterns | 77 | 2mo | Review | Intermediate |
| pr-review | 6 | 2mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
mflux-pr
filipstrand
Make a clean PR in mflux (inspect diff, quick verification, commit, push, open PR) using repo conventions.
python-testing-patterns
wshobson
Implement comprehensive testing strategies with pytest, fixtures, mocking, and test-driven development. Use when writing Python tests, setting up test suites, or implementing testing best practices.
pr-review
pytorch
Review PyTorch pull requests for code quality, test coverage, security, and backward compatibility. Use when reviewing PRs, when asked to review code changes, or when the user mentions "review PR", "code review", or "check this PR".
pytest
prowler-cloud
Pytest testing patterns for Python. Trigger: When writing or refactoring pytest tests (fixtures, mocking, parametrize, markers). For Prowler-specific API/SDK testing conventions, also use prowler-test-api or prowler-test-sdk.
ast-grep-find
parcadei
AST-based code search and refactoring via ast-grep MCP
code-change-verification
openai
Run the mandatory verification stack when changes affect runtime code, tests, or build/test behavior in the OpenAI Agents Python repository.