Confirmed users
574
edits
Better DXR Testing: Difference between revisions
→Strawman
| Line 15: | Line 15: | ||
Have one class that supports running tests against a concrete DXR instance—files and all. That'll be good for complex tests with many files where the FS is the least confusing place to express them. | Have one class that supports running tests against a concrete DXR instance—files and all. That'll be good for complex tests with many files where the FS is the least confusing place to express them. | ||
Another class can support simple tests that need a single file or so. (Fortunately, everything ends up as a single file in C anyway.) You'll provide code as a string that gets laid down in a dynamically generated instance and compiled. There'll be a flag or well-marked place to put a breakpoint to leave the instance around in case you want to interact with it manually. This should make tests trivial to write and solve the coupling problem. The downside is that tests will run slower, since there will be more build runs. | Another class can support simple tests that need a single file or so. (Fortunately, everything ends up as a single file in C anyway.) You'll provide code as a string that gets laid down in a dynamically generated instance and compiled. There'll be a flag or well-marked place to put a breakpoint to leave the instance around in case you want to interact with it manually. This should make tests trivial to write and solve the coupling problem. The downside is that tests will run slower, since there will be more build runs. We can probably at least apply nose's multiprocessor stuff to it if we keep the temp files separate. | ||