I've got a weird situation going on. Hopefully someone knows which
(probably simple) button to click to do to get it working the way i
want it.
I've got a largish solution full of different projects. also part of
the solution is a set of testing projects. one of the projects in the
solution is a web service (simple boring web service, not wcf or
anything). the web service project is set to, when debugging etc, use
the asp net file system based development web server, and is set to
always start listening on the same port (say, 2222). and that works
fine and when just running in the debugger everything is good and the
web service gets called on port 2222.
When i run unit tests, however, it somehow "knows" there's a web
service involved - and it starts the web service, but starts it on a
random port. All well and good, except that all my code that in the
other projects that call the web wervice pull the url to use from the
app.config file that specifies the port of 2222. End result - all the
calls to the web service fail because its been started on some other
port.
Interestingly, i've noticed two strange behaviours:
1) if i manually start a new debugging instance of the web service, it
will start on 2222. If i leave it running and then start the unit
tests, it ALSO starts teh web service on a random port, but the tests
i have that call code that invokes web service succeed because it can
connect on 2222.
2) one of my tests, so far, test a function that lives INSIDE the web
service and relies on a the HttpContext object. Iv'e decorated this
unit test saying HostType("ASP.NET"),
AspNetDevelopmentServerHost("file system path to the web service") and
UrlToTest("http://localhost:2222/WebForm1.aspx") ... and it happily
runs the test inside the file system web server...on the RANDOM port,
not port 2222 - which means the test always succeeds, regardless of
point 1) above.
I've read up on the webtesthelper.redirecturl (or words to that
effect) helper class, but that's no good because it works on a web
service reference object - and in my case the web service reference
object is buried deep within a class library - my test is calling a
public method on the class library that internally instantiates teh
web service object and invokes it, all based on config file values.
so in short - anyone know how to stop the test engine starting the web
service on a random port, but to start it on a fixed port instead?
--
Geoff Appleby
Blog: http://blogs.crankygoblin.com/blogs/geoff.appleby/