----- Original Message ----- From: "Glen Daniels" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 15, 2002 12:23 PM Subject: RE: dotnet local tests
> > > a playback server would be good, but since stage 2 of .net > > testing is to to > > do .net client, you still need install the framework. > > We can also trivially make up any given message and send it to our server (i.e. test.put). > > > Complex tests are anything that test round tripping, or > > particular .net > > versions (like 1.1 as well as 1.0) :- > > > > -are object references being preserved? > > -what does that version of .net do for out-of-range enums? > > -what does that version of .net generate for: complex data > > structures, char, > > rpc/enc vs doc/lit, etc. > > Hm - are you talking about actually testing .NET here, or simply using .NET to test Axis? If the former, I think that belongs in a separate project entirely. If the latter, couldn't you use playback to test this stuff? I'm figuring we can just build up a library of tests along with their canned responses/requests, and mostly not need a .NET installation at all to test most things. for playback we need to dynamically alter the returned WSDL to point to our emulated endpoints; the endpoints can just echo what they send in. For some of the complex stuff, like session handling, .net comes in to play. But really, once you've installed IIS/.net framework, deploying to .net to test is trivial, just a <copy> to the right place. Its the axis side tests that take up more time. What is your bias against .net other than it's wrong and evil? Gump integration? > > When we rely on complex behavior that spans more than a message or two, that's when we really need .NET to do the testing. I'm not really saying we shouldn't test with the actual .NET platform, just that we should, where possible, test the things that .NET uncovers for us in a way that integrates with our automated tests without a .NET server/client. well, I dont think it takes that much effort to run tests against a local (or adjacent) .net server. And we need to make sure that .net isnt regressing against Axis as it goes through its dev cycle, as much as we need to do the same w/ Axis against .net. I think adding client side .net tests against axis server is v. important, as that lets us ensure that net client works with axis servers, and that is something we cant tell so easily from the interop sites. We can test against other peoples server implementations, but we need them to tell us that our server doesnt work with their client. Local client side testing is faster. -Steve
