Tomas,

Now it makes sense why the tests were failing! If I find any real bugs I'll file them in JIRA.

Thanks a million!
Jon


PS. Your shameless plug has been duly noted. :)

Tomas Restrepo 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/






Reply via email to