Make default TestAgency URI unique per run #931
Conversation
|
You may be on to something, but I don't understand it well enough to be sure. What if the same port is chosen? Is it OK to have the same port so long as the uri portion is different? Can we test that by temporarily using a fixed value for the port? |
|
Yeah, that's a good point. I just did this quickly through the GitHub GUI following the adapter issue - I'll pull it down and add a test, it'll be simple enough. I think we also have some tests that include workarounds for this issue - I could remove those at the same time. |
ChrisMaddock
force-pushed
the
ChrisMaddock-patch-1
branch
from
b953e5a
to
83d6856
Compare
|
Ok, have filled this one out a little. 🙂 Added a test that failed before the change and passes afterwards - have tested this manually. Also removed the workarounds in out own test suite. This is good for review, but I've marked it blocked as I don't want to cause any merge conflicts with #937. Let's get that merged in first, and I'll rebase this one if required. 😄 |
|
Never mind...the test seems to be failing on the netcore build only with a mysterious NullReferenceException. That's the end of my time for today - this one will have to wait. 🙂 |
|
Replaced by #942 |
Currently, it's not possible to instantiate an engine inside a test run, due to two TestAgency's colliding on the same URI. This causes problems when testing runners and the engine, and requires injecting a second URI into the test TestAgency, which isn't possible for runners accessing the engine through the ITestEngine interface.
As far as I can think - a TestAgency URI needs to be fixed-per-run, but there's no requirement for it to be fixed across different runs. I think adding a GUID to the default TestAgency URI would be a simple change to resolve this problem, and make it easier for runners to test?
@CharliePoole - you've been working in this area recently - do you agree with my logic here?