Matthew Peters wrote:

> b) I am not sure if you are telling me that I need to do something
> here. Is there something I need to do in future that I have not been
> doing?

It's fine now. It was something you didn't do for this particular bug - 
which was in "feedback" (harsh turquoise) state at the time of this 
discussion - but I can see you are doing it now, as all the relevant 
bugs I can see are nicely assigned to "tuscany nnnn" in that fetching 

Don't 10989 and 10994 need closing in the PECL tracker now?

> c) Difficult in this particular case, especially because we did not
> know what we wanted the valid output to be. We just knew that we
> wanted it to validate with soapscope, oXygen and visual studio. Now
> that I know more about what the problems were I think the thing to do
> is to write a Java program to run both the generated WSDL and
> generated soap messages through XERCES. I will put this alongside the
> phpunit and phpt tests. I don't think I can do it in PHP since we
> never caught any of these problems with the PHP code.

I agree this is tough when we don't know the desired output. But I do 
believe it's still worth creating a testcase - the testcase must be 
skipped anyway until the solution is implemented, so the fact that it 
 >may< not be in its final form need not be an impediment.

For these particular defects, you are looking at the big picture and 
saying that the user requirement is that the WSDL validates with these 
external programs and we cannot develop php unit tests which will verify 
this. Of course you're right, and your Java test will be a valuable 
addition, I'm sure. But I don't agree with your conclusion that this 
means there is no meaningful regression test for these defects. For 
example, if a problem was that Tuscany generated two XML elements in the 
wrong order, then it's a SMOP to test that Tuscany now generates them in 
the right order - and (at least at this stage) the more of these tests 
we have the better, because such tests have a habit of finding other 
unexpected side-effects of changes that go into the code. If we make a 
habit of growing the test suite bottom-up in this way, we'll improve the 
  test coverage in the parts of the code that get most used.


You received this message because you are subscribed to the Google Groups 
"phpsoa" group.
To post to this group, send email to
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at

Reply via email to