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. Avoid using mocks or monkeypatching if possible. Attempt to test in a true environment with real objects and interactions. ### 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`.