Summary
Add integration tests that exercise the core tracing engine (Tracer._trace, get_trace_data, show_results) against real Python code, not just _is_user_code path filtering.
Problem
tests/test_tracer.py covers 12 scenarios for _is_user_code() (stdlib, site-packages, venv markers, symlinks, etc.) but does not verify that profiling actually records function calls, timings, callee relationships, or call-tree output. A regression in _trace() or get_trace_data() would go undetected.
Proposed Solution
Add a new test module (e.g. tests/test_tracer_integration.py) with small fixture scripts that:
- Start/stop a
Tracer around runpy.run_path() or an inline function call
- Assert
get_trace_data() returns expected function keys, call counts, and total times
- Cover
--ignore pattern filtering via _get_key() / _is_ignored()
- Cover exception stack unwinding (the fallback path in
_trace() when return frame doesn't match stack top)
- Optionally test the public API (
start_trace, stop_trace, show_results) exported from oracletrace/__init__.py
Use Case
The tracer is the core of OracleTrace. Integration tests give confidence that profiling, aggregation, and filtering work end-to-end — especially after changes to _trace() or user-code detection.
Example (optional)
# Fixture script: calls nested functions with known structure
def outer():
inner()
def inner():
pass
outer()
# Expected trace keys like "script.py:outer", "script.py:inner"
# Expected call_count and callee relationships
Alternatives Considered
- Extend
tests/test_tracer.py in place — possible, but separation keeps unit vs integration tests clear.
- Only add CLI-level tests — CLI tests mock
Tracer and would not catch engine regressions.
Additional Context
Currently untested in oracletrace/tracer.py:
_trace() call/return handling and exception unwind (lines 174–215)
get_trace_data() (lines 271–296)
show_results() table and logic-flow tree (lines 217–269)
- Public helpers
start_trace / stop_trace (lines 302–322)
Checklist
Summary
Add integration tests that exercise the core tracing engine (
Tracer._trace,get_trace_data,show_results) against real Python code, not just_is_user_codepath filtering.Problem
tests/test_tracer.pycovers 12 scenarios for_is_user_code()(stdlib, site-packages, venv markers, symlinks, etc.) but does not verify that profiling actually records function calls, timings, callee relationships, or call-tree output. A regression in_trace()orget_trace_data()would go undetected.Proposed Solution
Add a new test module (e.g.
tests/test_tracer_integration.py) with small fixture scripts that:Traceraroundrunpy.run_path()or an inline function callget_trace_data()returns expected function keys, call counts, and total times--ignorepattern filtering via_get_key()/_is_ignored()_trace()when return frame doesn't match stack top)start_trace,stop_trace,show_results) exported fromoracletrace/__init__.pyUse Case
The tracer is the core of OracleTrace. Integration tests give confidence that profiling, aggregation, and filtering work end-to-end — especially after changes to
_trace()or user-code detection.Example (optional)
Alternatives Considered
tests/test_tracer.pyin place — possible, but separation keeps unit vs integration tests clear.Tracerand would not catch engine regressions.Additional Context
Currently untested in
oracletrace/tracer.py:_trace()call/return handling and exception unwind (lines 174–215)get_trace_data()(lines 271–296)show_results()table and logic-flow tree (lines 217–269)start_trace/stop_trace(lines 302–322)Checklist