| | 1 | The profiling runcore requires an unusual testing strategy for a number of reasons. This page exists to list those reasons and to serve as a way to ensure that any the eventual testing framework addresses all concerns. |
| | 2 | |
| | 3 | == Issues == |
| | 4 | |
| | 5 | === randomness from timing information === |
| | 6 | A profile will contain a randomness in the form of timing information. It does not make sense to test for absolute values since tests must be able to succeed on slow machines as well as fast. It may make sense to test relative timing information, but even this is questionable. |
| | 7 | The best approach may be to enable the runcore to emit constant dummy timing information where all values are 1. This would also allow testing that times were added correctly and would simplify sanity checking. |
| | 8 | |
| | 9 | === data volume === |
| | 10 | The profile for even a short PIR program will be non-trivial in size. It must be easy for the testing code to specify which part of a profile it wants to test. Ideally the testing code would also avoid using PGE so that profiling tests could be run as part of coretest. |
