home / skills / dmitriiweb / extract-emails / pytest-testing-assistant

pytest-testing-assistant skill

safe

This skill helps you craft focused pytest tests as standalone functions, ensuring clear naming, single assertions, and readable structure.

npx playbooks add skill dmitriiweb/extract-emails --skill pytest-testing-assistant

Review the files below or copy the command above to add this skill to your agents.

Files (2)

SKILL.md

1.5 KB

---
name: pytest-testing-assistant
description: Write focused pytest tests as standalone functions (one test per function), avoiding test classes.
---

# Pytest Testing Assistant

## Quick start
- Write tests as plain functions; do not use test classes. Aim for one focused test per function/behavior.
- Use clear names: `test_<function>_<behavior>`; keep AAA (arrange/act/assert) obvious.
- Prefer one primary assertion per test; add minimal supporting checks when necessary.
- Use fixtures sparingly to keep tests readable; favor in-test setup when simple.
- Run with `pytest` or `pytest path/to/test_file.py` to scope runs.
- See `references/pytest_rules.md` for detailed guidelines and examples.

## Workflow
1) **Identify behavior**  
   - Target a single function/behavior per test. Name the test after the behavior being validated.  

2) **Write the test**  
   - Use a standalone function `def test_<thing>():` (no classes).  
   - Keep a clear arrange/act/assert structure; avoid hidden work in fixtures unless it improves clarity.  
   - Use parametrization for small input/output matrices instead of loops.  

3) **Assertions**  
   - Prefer one main assertion; add secondary checks only when they clarify the outcome.  
   - Include helpful assertion messages or use expressive matchers for readability.  

4) **Run and iterate**  
   - Run `pytest` (optionally narrow with paths or `-k` expressions).  
   - Refine names and setup for readability and isolation.  

## Reference
- `references/pytest_rules.md`: structure rules, naming patterns, and usage tips.

Overview

This skill generates focused pytest tests as standalone functions for a Python parser that extracts emails and LinkedIn account links from URLs. Tests follow a one-behavior-per-function approach, avoid test classes, and emphasize clear arrange/act/assert structure. The output is ready to drop into a test file and run with pytest.

How this skill works

Given a target function or behavior (for example: parse_emails_from_html, extract_linkedin_profiles, or parse_from_url), the skill emits one dedicated test function per behavior. Each test uses explicit inputs, invokes the parser, and asserts the primary expected outcome with minimal supporting checks. Parametrization is used for small input matrices and fixtures are suggested sparingly to keep each test readable and isolated.

When to use it

When adding or validating behavior for email extraction from HTML or fetched pages.
When verifying LinkedIn profile link extraction and normalization from raw URLs or anchor tags.
When refactoring parser code and needing tight, behavior-focused regression tests.
When onboarding contributors who need clear, single-purpose examples of expected behavior.
When building a small, maintainable test suite that runs fast and is easy to review.

Best practices

Write one test function per behavior, named test_<function>_<behavior> for clarity.
Prefer one primary assertion; include minimal secondary checks only when they add clarity.
Keep arrange/act/assert sections explicit and short; avoid hidden setup in many fixtures.
Use pytest.mark.parametrize for concise tables of input/output cases instead of loops.
Test normalization and edge cases: empty input, malformed HTML, duplicate addresses, and relative links.

Example use cases

test_parse_emails_simple: feed a snippet of HTML and assert the exact set of emails returned.
test_extract_linkedin_absolute_and_relative: ensure both absolute and relative LinkedIn hrefs are normalized to full profile URLs.
test_parse_from_url_handles_network_error: simulate a failed HTTP fetch and assert the function returns an empty list or raises a documented exception.
test_no_false_positive_emails: provide text that resembles emails but is invalid and assert the parser excludes them.

FAQ

Should I ever use test classes?

Avoid test classes here; use standalone functions to keep tests isolated and readable. Use fixtures only when they simplify repeated setup without hiding intent.

When should I parametrize tests?

Parametrize when you have a small matrix of input/output pairs that differ only by values. For complex scenarios prefer separate tests to keep failure messages focused.