You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Craig Stirling <CS...@uk.ibm.com> on 2005/07/25 14:40:29 UTC
Common code in tests
Looking through the tests it appears that lots of the code is common to
many tests. Included below is an example from a specific test case. I have
proceeded the common code with //example as well as making it an
alternative colour and bold.
There will be other bits of function that could be pulled out of testcases
into common test header files as well.
What do people think about the possibilty of separating common features
within tests into a header file that is used by all the tests - so code
wasn't duplicated and could be changed in one place.
=====================================================
#include "DataHandlerService.hpp"
#include <axis/AxisException.hpp>
#include <ctype.h>
#include <iostream>
#include <fstream>
#include <string.h>
#include <signal.h> //example
void sig_handler(int); //example
int main(int argc, char* argv[])
{
char endpoint[256];
const char* url="http://localhost:80/axis/DataHandlerService";
char *Result;
url = argv[1];
bool bSuccess = false;
int iRetryIterationCount = 3;
signal(SIGILL, sig_handler); //example
signal(SIGABRT, sig_handler); //example
signal(SIGSEGV, sig_handler); //example
//signal(SIGQUIT, sig_handler); //example
//signal(SIGBUS, sig_handler); //example
signal(SIGFPE, sig_handler); //example
do
{
try
{
sprintf(endpoint, "%s", url);
DataHandlerService ws(endpoint);
ISoapAttachment
*att=ws.createSoapAttachment();
char *text="This is a test message for
attachment";
//Adding the content type as text/plain
att->addHeader(AXIS_CONTENT_TYPE,"text/plain");
xsd__base64Binary b64b1;
b64b1.__ptr = (xsd__unsignedByte*)text;
b64b1.__size = strlen(text);
att->addBody(&b64b1);
//Calling the dataHandlerService, service
will return content
Result=ws.echoContent(att);
cout<<Result<<endl;
//Calling the dataHandlerService, service
will return content type
Result=ws.getContentType(att);
cout<<Result<<endl;
bSuccess = true;
}
catch(AxisException& e)
{
bool bSilent = false;
if( e.getExceptionCode() ==
CLIENT_TRANSPORT_OPEN_CONNECTION_FAILED)
{
if( iRetryIterationCount > 0)
{
bSilent = true;
}
}
else
{
iRetryIterationCount = 0;
}
if( !bSilent)
{
cout << "Exception : " << e.what() <<
endl;
}
}
catch(exception& e)
{
cout << "Unknown exception has occured" << endl;
}
catch(...)
{
cout << "Unknown exception has occured" << endl;
}
iRetryIterationCount--;
} while( iRetryIterationCount > 0 && !bSuccess);
cout<< "---------------------- TEST COMPLETE
-----------------------------"<< endl;
return 0;
}
void sig_handler(int sig) {
//example
signal(sig, sig_handler);
//example
cout << "SIGNAL RECEIVED " << sig << endl; //example
exit(1); //example
} //example
<==============================>
Craig Stirling
Web Services Client for C++ Test Coordinator
Tel: 249993
E-mail: craig@hursley.ibm.com
<==============================>
Re: Common code in tests
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Cool, I could use the "test.list" :-)
On 7/25/05, John Hawkins <HA...@uk.ibm.com> wrote:
>
> Perhaps you can just get away with a few key tests e.g. AxisBench for most
> times and then when you change some substantial function or a particular
> area that you don't know you can run all of them?
>
> I really think it's a benefit to have lots of small tests - waaaaay easier
> to debug :-)
>
>
>
>
>
> Samisa Abeysinghe <sa...@gmail.com>
>
> 25/07/2005 16:09
>
>
> Please respond to
> "Apache AXIS C Developers List"
>
>
> To Apache AXIS C Developers List <ax...@ws.apache.org>
>
> cc
>
> Subject Re: Common code in tests
>
>
>
>
>
> Yes I understood your suggestion to replace common code.
>
> My Suggestion to have a combined test was to make life easy specially
> wehn testing quick changes. With the current test framework, one of
> the problems that I have is that I have to run the whole test suite to
> check for side efects. However, if I had few tests then it would have
> been much easier to test minor/ncremental code changes.
>
>
>
> On 7/25/05, Craig Stirling <CS...@uk.ibm.com> wrote:
> >
> > Rather than grouping tests together my mail was suggesting that within
> the
> > current tests there is common code which could be replaced by calling a
> > central header file. This would reduce duplication of code within the
> tests.
> >
> > Creating more complex tests is a seperate issue. This often makes
> debugging
> > of failing tests very difficult. Less complicated tests in a specific
> area
> > are much easier to debug and maintain.
> >
> > Thanks
> > Craig
> >
> > <==============================>
> > Craig Stirling
> > Web Services Cleint for C++ Test Coordinator
> > Tel: 249993
> > E-mail: craig@hursley.ibm.com
> > <==============================>
> >
> >
> >
> >
> > Samisa Abeysinghe <sa...@gmail.com>
> >
> > 25-07-05 15:02
> >
> > Please respond to
> > "Apache AXIS C Developers List"
> >
> >
> > To Apache AXIS C Developers List <ax...@ws.apache.org>
> >
> > cc
> >
> > Subject Re: Common code in tests
> >
> >
> >
> >
> >
> > +1 from me too.
> >
> > I was infact once wondering of why not we have one large single test
> > to test for many scenarios at once rather than having several tests.
> > Like testing complex types, simple types and arrays could be combined
> > together into one test program and we could use exception model to
> > capture errors for different test scenarios within a single test
> > program.
> >
> > It is always easy to have few tests that cover the whole space.
> >
> > Thanks,
> > Samisa...
> >
> > On 7/25/05, Adrian Dick <ad...@uk.ibm.com> wrote:
> > > +1
> > >
> > > In addition to signal handling, it would also be good to include the
> MS
> > > VC++ 6 patch for cout of 64bit integers
> > > #ifdef WIN32
> > > #ifdef Q168440_WORKAROUND
> > > // Bug in MS Visual C++ 6.0. Fixed in Visual C++ .Net version.
> > > // Cannot print an __int64 number with cout without this overloading
> > > std::ostream& operator<<(std::ostream& os, __int64 i )
> > > {
> > > char buf[40];
> > > sprintf(buf,"%I64d", i );
> > > os << buf;
> > > return os;
> > > }
> > >
> > > std::ostream& operator<<(std::ostream& os, unsigned __int64 i )
> > > {
> > > char buf[20];
> > > sprintf(buf,"%I64u", i );
> > > os << buf;
> > > return os;
> > > }
> > > #endif
> > > #endif
> > >
> > >
> > > I'm sure there are also other things to consider - perhaps providing a
> > > macro to handle (unexpected) exceptions in a consistent manner?
> > >
> > > Regards,
> > > Adrian
> > > _______________________________________
> > > Adrian Dick (adrian.dick@uk.ibm.com)
> > >
> > >
> > > John Hawkins/UK/IBM@IBMGB wrote on 25/07/2005 14:10:25:
> > >
> > > >
> > > > +1
> > > > Good idea Craig.
> > > >
> > > >
> > > >
> > >
> > > >
> > > > Craig Stirling/UK/IBM@IBMGB
> > > > 25/07/2005 13:40
> > > >
> > > > Please respond to
> > > > "Apache AXIS C Developers List"
> > > >
> > > > To
> > > >
> > > > axis-c-dev@ws.apache.org
> > > >
> > > > cc
> > > >
> > > > Subject
> > > >
> > > > Common code in tests
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Looking through the tests it appears that lots of the code is common
> > > > to many tests. Included below is an example from a specific test
> > > > case. I have proceeded the common code with //example as well as
> > > > making it an alternative colour and bold.
> > > >
> > > > There will be other bits of function that could be pulled out of
> > > > testcases into common test header files as well.
> > > >
> > > > What do people think about the possibilty of separating common
> > > > features within tests into a header file that is used by all the
> > > > tests - so code wasn't duplicated and could be changed in one place.
> > > >
> > > >
> =====================================================
> > > >
> > > > #include "DataHandlerService.hpp"
> > > > #include <axis/AxisException.hpp>
> > > > #include <ctype.h>
> > > > #include <iostream>
> > > > #include <fstream>
> > > > #include <string.h>
> > > > #include <signal.h> //example
> > > >
> > > > void sig_handler(int); //example
> > > >
> > > > int main(int argc, char* argv[])
> > > > {
> > > > char endpoint[256];
> > > > const char*
> > url="http://localhost:80/axis/DataHandlerService";
> > >
> > > > char *Result;
> > > > url = argv[1];
> > > > bool bSuccess = false;
> > > > int iRetryIterationCount = 3;
> > > >
> > > > signal(SIGILL, sig_handler); //example
> > > > signal(SIGABRT, sig_handler); //example
> > > > signal(SIGSEGV, sig_handler); //example
> > > > //signal(SIGQUIT, sig_handler); //example
> > > > //signal(SIGBUS, sig_handler); //example
> > > > signal(SIGFPE, sig_handler); //example
> > > >
> > > > do
> > > > {
> > > > try
> > > > {
> > > > sprintf(endpoint, "%s", url);
> > > > DataHandlerService ws(endpoint);
> > > > ISoapAttachment *att=ws.
> > > > createSoapAttachment();
> > > > char *text="This is a test message
> > > > for attachment";
> > > > //Adding the content type as
> text/plain
> > > >
> > > att->addHeader(AXIS_CONTENT_TYPE,"text/plain");
> > > > xsd__base64Binary b64b1;
> > > > b64b1.__ptr =
> (xsd__unsignedByte*)text;
> > > > b64b1.__size = strlen(text);
> > >
> > > > att->addBody(&b64b1);
> > > > //Calling the dataHandlerService,
> > > > service will return content
> > > > Result=ws.echoContent(att);
> > >
> > > > cout<<Result<<endl;
> > > > //Calling the dataHandlerService,
> > > > service will return content type
> > > > Result=ws.getContentType(att);
> > > > cout<<Result<<endl;
> > > > bSuccess = true;
> > > > }
> > > > catch(AxisException& e)
> > > > {
> > > > bool bSilent = false;
> > > >
> > > > if( e.getExceptionCode() ==
> > > > CLIENT_TRANSPORT_OPEN_CONNECTION_FAILED)
> > > > {
> > > > if( iRetryIterationCount > 0)
> > > > {
> > > > bSilent = true;
> > > > }
> > > > }
> > > > else
> > > > {
> > > > iRetryIterationCount = 0;
> > > > }
> > > >
> > > > if( !bSilent)
> > > > {
> > > > cout << "Exception : " << e.what() <<
> > > endl;
> > > > }
> > > > }
> > > > catch(exception& e)
> > > > {
> > > > cout << "Unknown exception has occured" << endl;
> > > > }
> > > > catch(...)
> > > > {
> > > > cout << "Unknown exception has occured" << endl;
> > > > }
> > > > iRetryIterationCount--;
> > > > } while( iRetryIterationCount > 0 && !bSuccess);
> > > > cout<< "---------------------- TEST COMPLETE
> > > > -----------------------------"<< endl;
> > > >
> > > > return 0;
> > > > }
> > > >
> > > > void sig_handler(int sig) {
> > > > //example
> > > > signal(sig, sig_handler);
> > > //example
> > > > cout << "SIGNAL RECEIVED " << sig << endl; //example
> > > > exit(1);
> > >
> > > > //example
> > > > }
> > >
> > > > //example
> > > >
> > > >
> > > > <==============================>
> > > > Craig Stirling
> > > > Web Services Client for C++ Test Coordinator
> > > > Tel: 249993
> > > > E-mail: craig@hursley.ibm.com
> > > > <==============================>
> > >
> > >
> >
> >
> >
>
>
Re: Common code in tests
Posted by John Hawkins <HA...@uk.ibm.com>.
Perhaps you can just get away with a few key tests e.g. AxisBench for most
times and then when you change some substantial function or a particular
area that you don't know you can run all of them?
I really think it's a benefit to have lots of small tests - waaaaay easier
to debug :-)
Samisa Abeysinghe <sa...@gmail.com>
25/07/2005 16:09
Please respond to
"Apache AXIS C Developers List"
To
Apache AXIS C Developers List <ax...@ws.apache.org>
cc
Subject
Re: Common code in tests
Yes I understood your suggestion to replace common code.
My Suggestion to have a combined test was to make life easy specially
wehn testing quick changes. With the current test framework, one of
the problems that I have is that I have to run the whole test suite to
check for side efects. However, if I had few tests then it would have
been much easier to test minor/ncremental code changes.
On 7/25/05, Craig Stirling <CS...@uk.ibm.com> wrote:
>
> Rather than grouping tests together my mail was suggesting that within
the
> current tests there is common code which could be replaced by calling a
> central header file. This would reduce duplication of code within the
tests.
>
> Creating more complex tests is a seperate issue. This often makes
debugging
> of failing tests very difficult. Less complicated tests in a specific
area
> are much easier to debug and maintain.
>
> Thanks
> Craig
>
> <==============================>
> Craig Stirling
> Web Services Cleint for C++ Test Coordinator
> Tel: 249993
> E-mail: craig@hursley.ibm.com
> <==============================>
>
>
>
>
> Samisa Abeysinghe <sa...@gmail.com>
>
> 25-07-05 15:02
>
> Please respond to
> "Apache AXIS C Developers List"
>
>
> To Apache AXIS C Developers List <ax...@ws.apache.org>
>
> cc
>
> Subject Re: Common code in tests
>
>
>
>
>
> +1 from me too.
>
> I was infact once wondering of why not we have one large single test
> to test for many scenarios at once rather than having several tests.
> Like testing complex types, simple types and arrays could be combined
> together into one test program and we could use exception model to
> capture errors for different test scenarios within a single test
> program.
>
> It is always easy to have few tests that cover the whole space.
>
> Thanks,
> Samisa...
>
> On 7/25/05, Adrian Dick <ad...@uk.ibm.com> wrote:
> > +1
> >
> > In addition to signal handling, it would also be good to include the
MS
> > VC++ 6 patch for cout of 64bit integers
> > #ifdef WIN32
> > #ifdef Q168440_WORKAROUND
> > // Bug in MS Visual C++ 6.0. Fixed in Visual C++ .Net version.
> > // Cannot print an __int64 number with cout without this
overloading
> > std::ostream& operator<<(std::ostream& os, __int64 i )
> > {
> > char buf[40];
> > sprintf(buf,"%I64d", i );
> > os << buf;
> > return os;
> > }
> >
> > std::ostream& operator<<(std::ostream& os, unsigned __int64 i )
> > {
> > char buf[20];
> > sprintf(buf,"%I64u", i );
> > os << buf;
> > return os;
> > }
> > #endif
> > #endif
> >
> >
> > I'm sure there are also other things to consider - perhaps providing
a
> > macro to handle (unexpected) exceptions in a consistent manner?
> >
> > Regards,
> > Adrian
> > _______________________________________
> > Adrian Dick (adrian.dick@uk.ibm.com)
> >
> >
> > John Hawkins/UK/IBM@IBMGB wrote on 25/07/2005 14:10:25:
> >
> > >
> > > +1
> > > Good idea Craig.
> > >
> > >
> > >
> >
> > >
> > > Craig Stirling/UK/IBM@IBMGB
> > > 25/07/2005 13:40
> > >
> > > Please respond to
> > > "Apache AXIS C Developers List"
> > >
> > > To
> > >
> > > axis-c-dev@ws.apache.org
> > >
> > > cc
> > >
> > > Subject
> > >
> > > Common code in tests
> > >
> > >
> > >
> > >
> > >
> > > Looking through the tests it appears that lots of the code is
common
> > > to many tests. Included below is an example from a specific test
> > > case. I have proceeded the common code with //example as well as
> > > making it an alternative colour and bold.
> > >
> > > There will be other bits of function that could be pulled out of
> > > testcases into common test header files as well.
> > >
> > > What do people think about the possibilty of separating common
> > > features within tests into a header file that is used by all the
> > > tests - so code wasn't duplicated and could be changed in one
place.
> > >
> > > =====================================================
> > >
> > > #include "DataHandlerService.hpp"
> > > #include <axis/AxisException.hpp>
> > > #include <ctype.h>
> > > #include <iostream>
> > > #include <fstream>
> > > #include <string.h>
> > > #include <signal.h> //example
> > >
> > > void sig_handler(int); //example
> > >
> > > int main(int argc, char* argv[])
> > > {
> > > char endpoint[256];
> > > const char*
> url="http://localhost:80/axis/DataHandlerService";
> >
> > > char *Result;
> > > url = argv[1];
> > > bool bSuccess = false;
> > > int iRetryIterationCount = 3;
> > >
> > > signal(SIGILL, sig_handler); //example
> > > signal(SIGABRT, sig_handler); //example
> > > signal(SIGSEGV, sig_handler); //example
> > > //signal(SIGQUIT, sig_handler); //example
> > > //signal(SIGBUS, sig_handler); //example
> > > signal(SIGFPE, sig_handler); //example
> > >
> > > do
> > > {
> > > try
> > > {
> > > sprintf(endpoint, "%s", url);
> > > DataHandlerService ws(endpoint);
> > > ISoapAttachment *att=ws.
> > > createSoapAttachment();
> > > char *text="This is a test message
> > > for attachment";
> > > //Adding the content type as
text/plain
> > >
> > att->addHeader(AXIS_CONTENT_TYPE,"text/plain");
> > > xsd__base64Binary b64b1;
> > > b64b1.__ptr =
(xsd__unsignedByte*)text;
> > > b64b1.__size = strlen(text);
> >
> > > att->addBody(&b64b1);
> > > //Calling the dataHandlerService,
> > > service will return content
> > > Result=ws.echoContent(att);
> >
> > > cout<<Result<<endl;
> > > //Calling the dataHandlerService,
> > > service will return content type
> > > Result=ws.getContentType(att);
> > > cout<<Result<<endl;
> > > bSuccess = true;
> > > }
> > > catch(AxisException& e)
> > > {
> > > bool bSilent = false;
> > >
> > > if( e.getExceptionCode() ==
> > > CLIENT_TRANSPORT_OPEN_CONNECTION_FAILED)
> > > {
> > > if( iRetryIterationCount > 0)
> > > {
> > > bSilent = true;
> > > }
> > > }
> > > else
> > > {
> > > iRetryIterationCount = 0;
> > > }
> > >
> > > if( !bSilent)
> > > {
> > > cout << "Exception : " << e.what()
<<
> > endl;
> > > }
> > > }
> > > catch(exception& e)
> > > {
> > > cout << "Unknown exception has occured" << endl;
> > > }
> > > catch(...)
> > > {
> > > cout << "Unknown exception has occured" << endl;
> > > }
> > > iRetryIterationCount--;
> > > } while( iRetryIterationCount > 0 && !bSuccess);
> > > cout<< "---------------------- TEST COMPLETE
> > > -----------------------------"<< endl;
> > >
> > > return 0;
> > > }
> > >
> > > void sig_handler(int sig) {
> > > //example
> > > signal(sig, sig_handler);
> > //example
> > > cout << "SIGNAL RECEIVED " << sig << endl; //example
> > > exit(1);
> >
> > > //example
> > > }
> >
> > > //example
> > >
> > >
> > > <==============================>
> > > Craig Stirling
> > > Web Services Client for C++ Test Coordinator
> > > Tel: 249993
> > > E-mail: craig@hursley.ibm.com
> > > <==============================>
> >
> >
>
>
>
Re: Common code in tests
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Yes I understood your suggestion to replace common code.
My Suggestion to have a combined test was to make life easy specially
wehn testing quick changes. With the current test framework, one of
the problems that I have is that I have to run the whole test suite to
check for side efects. However, if I had few tests then it would have
been much easier to test minor/ncremental code changes.
On 7/25/05, Craig Stirling <CS...@uk.ibm.com> wrote:
>
> Rather than grouping tests together my mail was suggesting that within the
> current tests there is common code which could be replaced by calling a
> central header file. This would reduce duplication of code within the tests.
>
> Creating more complex tests is a seperate issue. This often makes debugging
> of failing tests very difficult. Less complicated tests in a specific area
> are much easier to debug and maintain.
>
> Thanks
> Craig
>
> <==============================>
> Craig Stirling
> Web Services Cleint for C++ Test Coordinator
> Tel: 249993
> E-mail: craig@hursley.ibm.com
> <==============================>
>
>
>
>
> Samisa Abeysinghe <sa...@gmail.com>
>
> 25-07-05 15:02
>
> Please respond to
> "Apache AXIS C Developers List"
>
>
> To Apache AXIS C Developers List <ax...@ws.apache.org>
>
> cc
>
> Subject Re: Common code in tests
>
>
>
>
>
> +1 from me too.
>
> I was infact once wondering of why not we have one large single test
> to test for many scenarios at once rather than having several tests.
> Like testing complex types, simple types and arrays could be combined
> together into one test program and we could use exception model to
> capture errors for different test scenarios within a single test
> program.
>
> It is always easy to have few tests that cover the whole space.
>
> Thanks,
> Samisa...
>
> On 7/25/05, Adrian Dick <ad...@uk.ibm.com> wrote:
> > +1
> >
> > In addition to signal handling, it would also be good to include the MS
> > VC++ 6 patch for cout of 64bit integers
> > #ifdef WIN32
> > #ifdef Q168440_WORKAROUND
> > // Bug in MS Visual C++ 6.0. Fixed in Visual C++ .Net version.
> > // Cannot print an __int64 number with cout without this overloading
> > std::ostream& operator<<(std::ostream& os, __int64 i )
> > {
> > char buf[40];
> > sprintf(buf,"%I64d", i );
> > os << buf;
> > return os;
> > }
> >
> > std::ostream& operator<<(std::ostream& os, unsigned __int64 i )
> > {
> > char buf[20];
> > sprintf(buf,"%I64u", i );
> > os << buf;
> > return os;
> > }
> > #endif
> > #endif
> >
> >
> > I'm sure there are also other things to consider - perhaps providing a
> > macro to handle (unexpected) exceptions in a consistent manner?
> >
> > Regards,
> > Adrian
> > _______________________________________
> > Adrian Dick (adrian.dick@uk.ibm.com)
> >
> >
> > John Hawkins/UK/IBM@IBMGB wrote on 25/07/2005 14:10:25:
> >
> > >
> > > +1
> > > Good idea Craig.
> > >
> > >
> > >
> >
> > >
> > > Craig Stirling/UK/IBM@IBMGB
> > > 25/07/2005 13:40
> > >
> > > Please respond to
> > > "Apache AXIS C Developers List"
> > >
> > > To
> > >
> > > axis-c-dev@ws.apache.org
> > >
> > > cc
> > >
> > > Subject
> > >
> > > Common code in tests
> > >
> > >
> > >
> > >
> > >
> > > Looking through the tests it appears that lots of the code is common
> > > to many tests. Included below is an example from a specific test
> > > case. I have proceeded the common code with //example as well as
> > > making it an alternative colour and bold.
> > >
> > > There will be other bits of function that could be pulled out of
> > > testcases into common test header files as well.
> > >
> > > What do people think about the possibilty of separating common
> > > features within tests into a header file that is used by all the
> > > tests - so code wasn't duplicated and could be changed in one place.
> > >
> > > =====================================================
> > >
> > > #include "DataHandlerService.hpp"
> > > #include <axis/AxisException.hpp>
> > > #include <ctype.h>
> > > #include <iostream>
> > > #include <fstream>
> > > #include <string.h>
> > > #include <signal.h> //example
> > >
> > > void sig_handler(int); //example
> > >
> > > int main(int argc, char* argv[])
> > > {
> > > char endpoint[256];
> > > const char*
> url="http://localhost:80/axis/DataHandlerService";
> >
> > > char *Result;
> > > url = argv[1];
> > > bool bSuccess = false;
> > > int iRetryIterationCount = 3;
> > >
> > > signal(SIGILL, sig_handler); //example
> > > signal(SIGABRT, sig_handler); //example
> > > signal(SIGSEGV, sig_handler); //example
> > > //signal(SIGQUIT, sig_handler); //example
> > > //signal(SIGBUS, sig_handler); //example
> > > signal(SIGFPE, sig_handler); //example
> > >
> > > do
> > > {
> > > try
> > > {
> > > sprintf(endpoint, "%s", url);
> > > DataHandlerService ws(endpoint);
> > > ISoapAttachment *att=ws.
> > > createSoapAttachment();
> > > char *text="This is a test message
> > > for attachment";
> > > //Adding the content type as text/plain
> > >
> > att->addHeader(AXIS_CONTENT_TYPE,"text/plain");
> > > xsd__base64Binary b64b1;
> > > b64b1.__ptr = (xsd__unsignedByte*)text;
> > > b64b1.__size = strlen(text);
> >
> > > att->addBody(&b64b1);
> > > //Calling the dataHandlerService,
> > > service will return content
> > > Result=ws.echoContent(att);
> >
> > > cout<<Result<<endl;
> > > //Calling the dataHandlerService,
> > > service will return content type
> > > Result=ws.getContentType(att);
> > > cout<<Result<<endl;
> > > bSuccess = true;
> > > }
> > > catch(AxisException& e)
> > > {
> > > bool bSilent = false;
> > >
> > > if( e.getExceptionCode() ==
> > > CLIENT_TRANSPORT_OPEN_CONNECTION_FAILED)
> > > {
> > > if( iRetryIterationCount > 0)
> > > {
> > > bSilent = true;
> > > }
> > > }
> > > else
> > > {
> > > iRetryIterationCount = 0;
> > > }
> > >
> > > if( !bSilent)
> > > {
> > > cout << "Exception : " << e.what() <<
> > endl;
> > > }
> > > }
> > > catch(exception& e)
> > > {
> > > cout << "Unknown exception has occured" << endl;
> > > }
> > > catch(...)
> > > {
> > > cout << "Unknown exception has occured" << endl;
> > > }
> > > iRetryIterationCount--;
> > > } while( iRetryIterationCount > 0 && !bSuccess);
> > > cout<< "---------------------- TEST COMPLETE
> > > -----------------------------"<< endl;
> > >
> > > return 0;
> > > }
> > >
> > > void sig_handler(int sig) {
> > > //example
> > > signal(sig, sig_handler);
> > //example
> > > cout << "SIGNAL RECEIVED " << sig << endl; //example
> > > exit(1);
> >
> > > //example
> > > }
> >
> > > //example
> > >
> > >
> > > <==============================>
> > > Craig Stirling
> > > Web Services Client for C++ Test Coordinator
> > > Tel: 249993
> > > E-mail: craig@hursley.ibm.com
> > > <==============================>
> >
> >
>
>
>
Re: Common code in tests
Posted by Craig Stirling <CS...@uk.ibm.com>.
Rather than grouping tests together my mail was suggesting that within the
current tests there is common code which could be replaced by calling a
central header file. This would reduce duplication of code within the
tests.
Creating more complex tests is a seperate issue. This often makes
debugging of failing tests very difficult. Less complicated tests in a
specific area are much easier to debug and maintain.
Thanks
Craig
<==============================>
Craig Stirling
Web Services Cleint for C++ Test Coordinator
Tel: 249993
E-mail: craig@hursley.ibm.com
<==============================>
Samisa Abeysinghe <sa...@gmail.com>
25-07-05 15:02
Please respond to
"Apache AXIS C Developers List"
To
Apache AXIS C Developers List <ax...@ws.apache.org>
cc
Subject
Re: Common code in tests
+1 from me too.
I was infact once wondering of why not we have one large single test
to test for many scenarios at once rather than having several tests.
Like testing complex types, simple types and arrays could be combined
together into one test program and we could use exception model to
capture errors for different test scenarios within a single test
program.
It is always easy to have few tests that cover the whole space.
Thanks,
Samisa...
On 7/25/05, Adrian Dick <ad...@uk.ibm.com> wrote:
> +1
>
> In addition to signal handling, it would also be good to include the MS
> VC++ 6 patch for cout of 64bit integers
> #ifdef WIN32
> #ifdef Q168440_WORKAROUND
> // Bug in MS Visual C++ 6.0. Fixed in Visual C++ .Net version.
> // Cannot print an __int64 number with cout without this overloading
> std::ostream& operator<<(std::ostream& os, __int64 i )
> {
> char buf[40];
> sprintf(buf,"%I64d", i );
> os << buf;
> return os;
> }
>
> std::ostream& operator<<(std::ostream& os, unsigned __int64 i )
> {
> char buf[20];
> sprintf(buf,"%I64u", i );
> os << buf;
> return os;
> }
> #endif
> #endif
>
>
> I'm sure there are also other things to consider - perhaps providing a
> macro to handle (unexpected) exceptions in a consistent manner?
>
> Regards,
> Adrian
> _______________________________________
> Adrian Dick (adrian.dick@uk.ibm.com)
>
>
> John Hawkins/UK/IBM@IBMGB wrote on 25/07/2005 14:10:25:
>
> >
> > +1
> > Good idea Craig.
> >
> >
> >
>
> >
> > Craig Stirling/UK/IBM@IBMGB
> > 25/07/2005 13:40
> >
> > Please respond to
> > "Apache AXIS C Developers List"
> >
> > To
> >
> > axis-c-dev@ws.apache.org
> >
> > cc
> >
> > Subject
> >
> > Common code in tests
> >
> >
> >
> >
> >
> > Looking through the tests it appears that lots of the code is common
> > to many tests. Included below is an example from a specific test
> > case. I have proceeded the common code with //example as well as
> > making it an alternative colour and bold.
> >
> > There will be other bits of function that could be pulled out of
> > testcases into common test header files as well.
> >
> > What do people think about the possibilty of separating common
> > features within tests into a header file that is used by all the
> > tests - so code wasn't duplicated and could be changed in one place.
> >
> > =====================================================
> >
> > #include "DataHandlerService.hpp"
> > #include <axis/AxisException.hpp>
> > #include <ctype.h>
> > #include <iostream>
> > #include <fstream>
> > #include <string.h>
> > #include <signal.h> //example
> >
> > void sig_handler(int); //example
> >
> > int main(int argc, char* argv[])
> > {
> > char endpoint[256];
> > const char* url="http://localhost:80/axis/DataHandlerService";
>
> > char *Result;
> > url = argv[1];
> > bool bSuccess = false;
> > int iRetryIterationCount = 3;
> >
> > signal(SIGILL, sig_handler); //example
> > signal(SIGABRT, sig_handler); //example
> > signal(SIGSEGV, sig_handler); //example
> > //signal(SIGQUIT, sig_handler); //example
> > //signal(SIGBUS, sig_handler); //example
> > signal(SIGFPE, sig_handler); //example
> >
> > do
> > {
> > try
> > {
> > sprintf(endpoint, "%s", url);
> > DataHandlerService ws(endpoint);
> > ISoapAttachment *att=ws.
> > createSoapAttachment();
> > char *text="This is a test message
> > for attachment";
> > //Adding the content type as text/plain
> >
> att->addHeader(AXIS_CONTENT_TYPE,"text/plain");
> > xsd__base64Binary b64b1;
> > b64b1.__ptr = (xsd__unsignedByte*)text;
> > b64b1.__size = strlen(text);
>
> > att->addBody(&b64b1);
> > //Calling the dataHandlerService,
> > service will return content
> > Result=ws.echoContent(att);
>
> > cout<<Result<<endl;
> > //Calling the dataHandlerService,
> > service will return content type
> > Result=ws.getContentType(att);
> > cout<<Result<<endl;
> > bSuccess = true;
> > }
> > catch(AxisException& e)
> > {
> > bool bSilent = false;
> >
> > if( e.getExceptionCode() ==
> > CLIENT_TRANSPORT_OPEN_CONNECTION_FAILED)
> > {
> > if( iRetryIterationCount > 0)
> > {
> > bSilent = true;
> > }
> > }
> > else
> > {
> > iRetryIterationCount = 0;
> > }
> >
> > if( !bSilent)
> > {
> > cout << "Exception : " << e.what() <<
> endl;
> > }
> > }
> > catch(exception& e)
> > {
> > cout << "Unknown exception has occured" << endl;
> > }
> > catch(...)
> > {
> > cout << "Unknown exception has occured" << endl;
> > }
> > iRetryIterationCount--;
> > } while( iRetryIterationCount > 0 && !bSuccess);
> > cout<< "---------------------- TEST COMPLETE
> > -----------------------------"<< endl;
> >
> > return 0;
> > }
> >
> > void sig_handler(int sig) {
> > //example
> > signal(sig, sig_handler);
> //example
> > cout << "SIGNAL RECEIVED " << sig << endl; //example
> > exit(1);
>
> > //example
> > }
>
> > //example
> >
> >
> > <==============================>
> > Craig Stirling
> > Web Services Client for C++ Test Coordinator
> > Tel: 249993
> > E-mail: craig@hursley.ibm.com
> > <==============================>
>
>
Re: Common code in tests
Posted by Samisa Abeysinghe <sa...@gmail.com>.
+1 from me too.
I was infact once wondering of why not we have one large single test
to test for many scenarios at once rather than having several tests.
Like testing complex types, simple types and arrays could be combined
together into one test program and we could use exception model to
capture errors for different test scenarios within a single test
program.
It is always easy to have few tests that cover the whole space.
Thanks,
Samisa...
On 7/25/05, Adrian Dick <ad...@uk.ibm.com> wrote:
> +1
>
> In addition to signal handling, it would also be good to include the MS
> VC++ 6 patch for cout of 64bit integers
> #ifdef WIN32
> #ifdef Q168440_WORKAROUND
> // Bug in MS Visual C++ 6.0. Fixed in Visual C++ .Net version.
> // Cannot print an __int64 number with cout without this overloading
> std::ostream& operator<<(std::ostream& os, __int64 i )
> {
> char buf[40];
> sprintf(buf,"%I64d", i );
> os << buf;
> return os;
> }
>
> std::ostream& operator<<(std::ostream& os, unsigned __int64 i )
> {
> char buf[20];
> sprintf(buf,"%I64u", i );
> os << buf;
> return os;
> }
> #endif
> #endif
>
>
> I'm sure there are also other things to consider - perhaps providing a
> macro to handle (unexpected) exceptions in a consistent manner?
>
> Regards,
> Adrian
> _______________________________________
> Adrian Dick (adrian.dick@uk.ibm.com)
>
>
> John Hawkins/UK/IBM@IBMGB wrote on 25/07/2005 14:10:25:
>
> >
> > +1
> > Good idea Craig.
> >
> >
> >
>
> >
> > Craig Stirling/UK/IBM@IBMGB
> > 25/07/2005 13:40
> >
> > Please respond to
> > "Apache AXIS C Developers List"
> >
> > To
> >
> > axis-c-dev@ws.apache.org
> >
> > cc
> >
> > Subject
> >
> > Common code in tests
> >
> >
> >
> >
> >
> > Looking through the tests it appears that lots of the code is common
> > to many tests. Included below is an example from a specific test
> > case. I have proceeded the common code with //example as well as
> > making it an alternative colour and bold.
> >
> > There will be other bits of function that could be pulled out of
> > testcases into common test header files as well.
> >
> > What do people think about the possibilty of separating common
> > features within tests into a header file that is used by all the
> > tests - so code wasn't duplicated and could be changed in one place.
> >
> > =====================================================
> >
> > #include "DataHandlerService.hpp"
> > #include <axis/AxisException.hpp>
> > #include <ctype.h>
> > #include <iostream>
> > #include <fstream>
> > #include <string.h>
> > #include <signal.h> //example
> >
> > void sig_handler(int); //example
> >
> > int main(int argc, char* argv[])
> > {
> > char endpoint[256];
> > const char* url="http://localhost:80/axis/DataHandlerService";
>
> > char *Result;
> > url = argv[1];
> > bool bSuccess = false;
> > int iRetryIterationCount = 3;
> >
> > signal(SIGILL, sig_handler); //example
> > signal(SIGABRT, sig_handler); //example
> > signal(SIGSEGV, sig_handler); //example
> > //signal(SIGQUIT, sig_handler); //example
> > //signal(SIGBUS, sig_handler); //example
> > signal(SIGFPE, sig_handler); //example
> >
> > do
> > {
> > try
> > {
> > sprintf(endpoint, "%s", url);
> > DataHandlerService ws(endpoint);
> > ISoapAttachment *att=ws.
> > createSoapAttachment();
> > char *text="This is a test message
> > for attachment";
> > //Adding the content type as text/plain
> >
> att->addHeader(AXIS_CONTENT_TYPE,"text/plain");
> > xsd__base64Binary b64b1;
> > b64b1.__ptr = (xsd__unsignedByte*)text;
> > b64b1.__size = strlen(text);
>
> > att->addBody(&b64b1);
> > //Calling the dataHandlerService,
> > service will return content
> > Result=ws.echoContent(att);
>
> > cout<<Result<<endl;
> > //Calling the dataHandlerService,
> > service will return content type
> > Result=ws.getContentType(att);
> > cout<<Result<<endl;
> > bSuccess = true;
> > }
> > catch(AxisException& e)
> > {
> > bool bSilent = false;
> >
> > if( e.getExceptionCode() ==
> > CLIENT_TRANSPORT_OPEN_CONNECTION_FAILED)
> > {
> > if( iRetryIterationCount > 0)
> > {
> > bSilent = true;
> > }
> > }
> > else
> > {
> > iRetryIterationCount = 0;
> > }
> >
> > if( !bSilent)
> > {
> > cout << "Exception : " << e.what() <<
> endl;
> > }
> > }
> > catch(exception& e)
> > {
> > cout << "Unknown exception has occured" << endl;
> > }
> > catch(...)
> > {
> > cout << "Unknown exception has occured" << endl;
> > }
> > iRetryIterationCount--;
> > } while( iRetryIterationCount > 0 && !bSuccess);
> > cout<< "---------------------- TEST COMPLETE
> > -----------------------------"<< endl;
> >
> > return 0;
> > }
> >
> > void sig_handler(int sig) {
> > //example
> > signal(sig, sig_handler);
> //example
> > cout << "SIGNAL RECEIVED " << sig << endl; //example
> > exit(1);
>
> > //example
> > }
>
> > //example
> >
> >
> > <==============================>
> > Craig Stirling
> > Web Services Client for C++ Test Coordinator
> > Tel: 249993
> > E-mail: craig@hursley.ibm.com
> > <==============================>
>
>
Re: Common code in tests
Posted by Adrian Dick <ad...@uk.ibm.com>.
+1
In addition to signal handling, it would also be good to include the MS
VC++ 6 patch for cout of 64bit integers
#ifdef WIN32
#ifdef Q168440_WORKAROUND
// Bug in MS Visual C++ 6.0. Fixed in Visual C++ .Net version.
// Cannot print an __int64 number with cout without this overloading
std::ostream& operator<<(std::ostream& os, __int64 i )
{
char buf[40];
sprintf(buf,"%I64d", i );
os << buf;
return os;
}
std::ostream& operator<<(std::ostream& os, unsigned __int64 i )
{
char buf[20];
sprintf(buf,"%I64u", i );
os << buf;
return os;
}
#endif
#endif
I'm sure there are also other things to consider - perhaps providing a
macro to handle (unexpected) exceptions in a consistent manner?
Regards,
Adrian
_______________________________________
Adrian Dick (adrian.dick@uk.ibm.com)
John Hawkins/UK/IBM@IBMGB wrote on 25/07/2005 14:10:25:
>
> +1
> Good idea Craig.
>
>
>
>
> Craig Stirling/UK/IBM@IBMGB
> 25/07/2005 13:40
>
> Please respond to
> "Apache AXIS C Developers List"
>
> To
>
> axis-c-dev@ws.apache.org
>
> cc
>
> Subject
>
> Common code in tests
>
>
>
>
>
> Looking through the tests it appears that lots of the code is common
> to many tests. Included below is an example from a specific test
> case. I have proceeded the common code with //example as well as
> making it an alternative colour and bold.
>
> There will be other bits of function that could be pulled out of
> testcases into common test header files as well.
>
> What do people think about the possibilty of separating common
> features within tests into a header file that is used by all the
> tests - so code wasn't duplicated and could be changed in one place.
>
> =====================================================
>
> #include "DataHandlerService.hpp"
> #include <axis/AxisException.hpp>
> #include <ctype.h>
> #include <iostream>
> #include <fstream>
> #include <string.h>
> #include <signal.h> //example
>
> void sig_handler(int); //example
>
> int main(int argc, char* argv[])
> {
> char endpoint[256];
> const char* url="http://localhost:80/axis/DataHandlerService";
> char *Result;
> url = argv[1];
> bool bSuccess = false;
> int iRetryIterationCount = 3;
>
> signal(SIGILL, sig_handler); //example
> signal(SIGABRT, sig_handler); //example
> signal(SIGSEGV, sig_handler); //example
> //signal(SIGQUIT, sig_handler); //example
> //signal(SIGBUS, sig_handler); //example
> signal(SIGFPE, sig_handler); //example
>
> do
> {
> try
> {
> sprintf(endpoint, "%s", url);
> DataHandlerService ws(endpoint);
> ISoapAttachment *att=ws.
> createSoapAttachment();
> char *text="This is a test message
> for attachment";
> //Adding the content type as text/plain
>
att->addHeader(AXIS_CONTENT_TYPE,"text/plain");
> xsd__base64Binary b64b1;
> b64b1.__ptr = (xsd__unsignedByte*)text;
> b64b1.__size = strlen(text);
> att->addBody(&b64b1);
> //Calling the dataHandlerService,
> service will return content
> Result=ws.echoContent(att);
> cout<<Result<<endl;
> //Calling the dataHandlerService,
> service will return content type
> Result=ws.getContentType(att);
> cout<<Result<<endl;
> bSuccess = true;
> }
> catch(AxisException& e)
> {
> bool bSilent = false;
>
> if( e.getExceptionCode() ==
> CLIENT_TRANSPORT_OPEN_CONNECTION_FAILED)
> {
> if( iRetryIterationCount > 0)
> {
> bSilent = true;
> }
> }
> else
> {
> iRetryIterationCount = 0;
> }
>
> if( !bSilent)
> {
> cout << "Exception : " << e.what() <<
endl;
> }
> }
> catch(exception& e)
> {
> cout << "Unknown exception has occured" << endl;
> }
> catch(...)
> {
> cout << "Unknown exception has occured" << endl;
> }
> iRetryIterationCount--;
> } while( iRetryIterationCount > 0 && !bSuccess);
> cout<< "---------------------- TEST COMPLETE
> -----------------------------"<< endl;
>
> return 0;
> }
>
> void sig_handler(int sig) {
> //example
> signal(sig, sig_handler);
//example
> cout << "SIGNAL RECEIVED " << sig << endl; //example
> exit(1);
> //example
> }
> //example
>
>
> <==============================>
> Craig Stirling
> Web Services Client for C++ Test Coordinator
> Tel: 249993
> E-mail: craig@hursley.ibm.com
> <==============================>
Re: Common code in tests
Posted by John Hawkins <HA...@uk.ibm.com>.
+1
Good idea Craig.
Craig Stirling/UK/IBM@IBMGB
25/07/2005 13:40
Please respond to
"Apache AXIS C Developers List"
To
axis-c-dev@ws.apache.org
cc
Subject
Common code in tests
Looking through the tests it appears that lots of the code is common to
many tests. Included below is an example from a specific test case. I have
proceeded the common code with //example as well as making it an
alternative colour and bold.
There will be other bits of function that could be pulled out of testcases
into common test header files as well.
What do people think about the possibilty of separating common features
within tests into a header file that is used by all the tests - so code
wasn't duplicated and could be changed in one place.
=====================================================
#include "DataHandlerService.hpp"
#include <axis/AxisException.hpp>
#include <ctype.h>
#include <iostream>
#include <fstream>
#include <string.h>
#include <signal.h> //example
void sig_handler(int); //example
int main(int argc, char* argv[])
{
char endpoint[256];
const char* url="http://localhost:80/axis/DataHandlerService";
char *Result;
url = argv[1];
bool bSuccess = false;
int iRetryIterationCount = 3;
signal(SIGILL, sig_handler); //example
signal(SIGABRT, sig_handler); //example
signal(SIGSEGV, sig_handler); //example
//signal(SIGQUIT, sig_handler); //example
//signal(SIGBUS, sig_handler); //example
signal(SIGFPE, sig_handler); //example
do
{
try
{
sprintf(endpoint, "%s", url);
DataHandlerService ws(endpoint);
ISoapAttachment
*att=ws.createSoapAttachment();
char *text="This is a test message for
attachment";
//Adding the content type as text/plain
att->addHeader(AXIS_CONTENT_TYPE,"text/plain");
xsd__base64Binary b64b1;
b64b1.__ptr = (xsd__unsignedByte*)text;
b64b1.__size = strlen(text);
att->addBody(&b64b1);
//Calling the dataHandlerService, service
will return content
Result=ws.echoContent(att);
cout<<Result<<endl;
//Calling the dataHandlerService, service
will return content type
Result=ws.getContentType(att);
cout<<Result<<endl;
bSuccess = true;
}
catch(AxisException& e)
{
bool bSilent = false;
if( e.getExceptionCode() ==
CLIENT_TRANSPORT_OPEN_CONNECTION_FAILED)
{
if( iRetryIterationCount > 0)
{
bSilent = true;
}
}
else
{
iRetryIterationCount = 0;
}
if( !bSilent)
{
cout << "Exception : " << e.what() <<
endl;
}
}
catch(exception& e)
{
cout << "Unknown exception has occured" << endl;
}
catch(...)
{
cout << "Unknown exception has occured" << endl;
}
iRetryIterationCount--;
} while( iRetryIterationCount > 0 && !bSuccess);
cout<< "---------------------- TEST COMPLETE
-----------------------------"<< endl;
return 0;
}
void sig_handler(int sig) {
//example
signal(sig, sig_handler);
//example
cout << "SIGNAL RECEIVED " << sig << endl; //example
exit(1); //example
} //example
<==============================>
Craig Stirling
Web Services Client for C++ Test Coordinator
Tel: 249993
E-mail: craig@hursley.ibm.com
<==============================>