Confirmed users
574
edits
Better DXR Testing: Difference between revisions
Jump to navigation
Jump to search
m
→Problems to solve: grammar
(→Problems to solve: Noted that the tested server runs in a different process than the testrunner.) |
m (→Problems to solve: grammar) |
||
| Line 2: | Line 2: | ||
== Problems to solve == | == Problems to solve == | ||
* It's hard to make a new test. You have to duplicate a lot of boilerplate, change dir names in said boilerplate, and the number of files | * It's hard to make a new test. You have to duplicate a lot of boilerplate, change dir names in said boilerplate, and the number of files goes way up. | ||
* We have to write our own lame testrunner: that "global failed" thing in search-test.py that keeps track of whether any tests have failed. And there's a bare except in there. We would rather not maintain any pieces of our own testrunner that we don't have to. We *certainly* don't want to duplicate them. | * We have to write our own lame testrunner: that "global failed" thing in search-test.py that keeps track of whether any tests have failed. And there's a bare except in there. We would rather not maintain any pieces of our own testrunner that we don't have to. We *certainly* don't want to duplicate them. | ||
* There's another layer of custom test framework: run-tests.py. Right now, it's a spaghetti of shell scripts and sleeps. Surely at least we can share some common setup and teardown. | * There's another layer of custom test framework: run-tests.py. Right now, it's a spaghetti of shell scripts and sleeps. Surely at least we can share some common setup and teardown. | ||