Better DXR Testing: Difference between revisions

Better DXR Testing (view source)

163 bytes added , 12 February 2013

Confirmed users

574

edits

@@ Line 13: / Line 13: @@
 == Strawman ==
-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.) It'll include 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.
+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.