Closed dodie closed 5 years ago
Also consider removing the explicit methods to track primitive values
I decided to keep the dedicated methods for primitive tracking because it results in a simpler instrumentation code, and also more flexible (e.g. allows to differentiate between primitive and reference types in the runtime API.)
Future Ideas:
Separate the instrumentation and the test reporting runtime into separate modules. Separate an API module. With a non-static API, an interface can help consistency, because this way Scott can provide an interface that the runtime classes can implement.
For simplicity reasons, I decided to keep the module in one package. The runtime part only has provided dependencies, so it's not a big problem for now.
For now, trackMethodStart does not have line number of the context.
Now all tracking methods receive the correct line number.
Make sure methods are consistent in the runtime API:
Update documentation with all the changes in 3.5.0, including dev docs on how the instrumentation works, and how new modules could use it.
Future Ideas: