As Thomas pointed out, these tests were not unit tests, but more like integration tests. I removed/commented some of them out in an effort to try and get down to just those that would run in a fully automated way.
They should really be moved into an integration test package. Service requesting/providing need to be run as a pair. To try and get a better automated tests suite, they should really be combined together into a single NUnit test that does both ends. Have you tried running them with a broker started on default localhost/port? I think headers exchange tests ought to pass like that. Rupert On 22/03/07, Tomas Restrepo <[EMAIL PROTECTED]> wrote:
Jon, > I just discovered that several of the unit tests for the .NET client > are failing or have been disabled. I've only started running these > recently (past day or two) so I don't know how long they have been in > this state. I wanted to bring this up just in case it would affect the > release in any way. The tests are as follows: > > Qpid.Client.Tests.ServiceRequestingClient: disabled > Qpid.Client.Tests.failover.FailoverTest: disabled > Qpid.Client.Tests.failover.FailoverTxTest: disabled > Qpid.Client.Tests.ServiceProvidingClient: disabled > Qpid.Client.Tests.HeadersExchangeTest: 3/4 tests fail I haven't checked on the status of all of them, but here's the crux of the issue: Right now, the test suites in the .NET client are a mixture of independent, real unit tests and a bunch of integration-level tests that require certain environment support to be available. For example, the Qpid.Buffer tests are your usual standalone unit tests, but the most of the tests in Qpid.Client.Tests require a running broker to connect to. One of the issues here is that some of the tests required even more. For example, I think the failover tests required you to be running a broker to failover to, as well as fail the primary broker manually at the right time. I don't think many of us are running such an environment and are willing to manually do those tricks every time the test suite run :) I'm not sure about the other tests, but I think the ServiceProvidingClient and ServiceRequestingClient tests were meant to be run at the same time to talk to one another (which would 90% of the time not be the case of how one would run them). The end result was that all the stuff like this just caused the tests to hang for a long time if you made the mistake of running the entire test suite at once. I think Rupert may know a bit more about these than I do. I'll be the first to admit that the current state of affairs is not good, and we definitely need to solve this. From one side, I think that tests such as ServiceProvidingClient and ServiceRequestingClient would be better off moving to the new interop testing infrastructure that Rupert Smith has been working on (though work on implementing the necessary support for the .NET client has not begun yet). Shameless Plug: The truth is the .NET client still needs a *lot* of work to reach the level of maturity the Java client has. We've done tremendous progress of the past couple of months, but we need to do more, and any help in doing so would be gladly welcome. If you'd like to contribute code and patches, they'd be really appreciated, though even just bringing up any issues you run into and filing bugs is of significant help! Tomas Restrepo http://www.winterdom.com/weblog/
