# Writing Tests

> This skill is used for writing tests to aid developers in ensuring code works properly. Use when a user mentions "writing tests", "adding code coverage", "testing new feature", asks to "write unit tests", or says "write a unit test for" something specific.

- Skill: `ansys/writing-tests` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ansys/writing-tests`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ansys/writing-tests/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ansys (https://skillmd.com/u/ansys)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ansys/writing-tests

---


# Writing Tests

## Instructions

### Step 1: Activate virtual environment
Look for a `.venv` directory in the current workspace folder (e.g. `pyansys-geometry/.venv`). If one exists, activate it.
If no `.venv` exists in the current directory, check the parent directory for a `.venv`. If one exists there, activate it instead.
If no virtual environment is found in either location, follow the instructions under `.github/copilot-instructions.md` for "Install (developer)" to create and install one.
Ex: Call `./.venv/Scripts/Activate.ps1` (Windows) or `source ./.venv/bin/activate` (Linux/macOS) from the directory containing the virtual environment.

### Step 2: Write the test(s)
Read any code that the user references.
If the user does not specify a specific file to write the tests in, go in the tests folder, and find the most relevant test file.
If no other test file is relevant, consider creating a new file.
Tests that require a modeler session need to be added to the "integration" folder.
Leverage the pytest fixtures available for handling modeler sessions.
Write test code to test code in a detailed way. For example, if the code alters a face, test the before and after area of the face.
Document briefly what the test is doing through a docstring.
If the code to be tested has paths that raise errors, test those scenarios.

### Step 3: Run the test and verify results
Change directory into the pyansys-geometry directory.
Run the test by calling "pytest --use-existing-service=yes -k TEST_NAME", replacing TEST_NAME with the new test.
Assume the calling developer has a server running.
If the test fails, figure out why and iterate the source code or test code to fix it.
If the test fails and needs server-side changes, raise that to the user.

### Reducing line count
- **Inline sketch creation** using method chaining: `Sketch()` methods like `.box()`, `.circle()`, `.slot()` etc. all return `self`, so pass them directly: `design.extrude_sketch("Box", Sketch().box(Point2D([0, 0]), 1, 1), 1)` instead of assigning to an intermediate variable.
- **Eliminate single-use variables** when the value is only referenced once. If a value is used more than once, store it in a variable to avoid repeated property access.
- **Inline `len()` checks** rather than assigning the list to a variable just to call `len()` on it.

### Linting and line length
- The project enforces a **100-character maximum line length**. Every line must stay within this limit.
- When a line would exceed 100 characters, break it using Python's implicit line continuation inside parentheses:
  ```python
  # Too long:
  assert sum(mappable for _, mappable in results) == 6, "All 6 flat box faces should be mappable"
  # Fixed — drop the message or wrap:
  assert sum(mappable for _, mappable in results) == 6
  ```
- Drop inline assertion messages when they push the line over the limit; the asserted expression is usually self-documenting.
- After writing tests, run `pre-commit run --files <test_file>` or check line lengths manually to catch any violations before running pytest.

### Assertion quality
- **Never use `> 0` as a test condition.** Always assert exact expected values (e.g. `== 6`, `== 1`, `== 0`). If the exact value is not obvious from the geometry or logic, run the test once to observe the actual return value, then hard-code that exact value as the assertion.
- Prefer specific assertions over vague ones: `assert count == 6` is better than `assert count > 0`; `assert len(results) == 3` is better than `assert len(results) > 0`.