unit test
-
I'm working with VC++6.0. I have a SDI application. I want to do unit test on some functions, but how do I run it? Say I have a function BOOL IsValid (MyType *p); And the unit test I write for it is: void TestIsValid() When I run my application in Debug mode, how can I run "TestIsValid"? Thank you very much for any help!
-
I'm working with VC++6.0. I have a SDI application. I want to do unit test on some functions, but how do I run it? Say I have a function BOOL IsValid (MyType *p); And the unit test I write for it is: void TestIsValid() When I run my application in Debug mode, how can I run "TestIsValid"? Thank you very much for any help!
Use the
#ifdefand#endifblocks:BOOL IsValid (MyType *p) {
// do something
#ifdef _DEBUG
TestIsValid();
#endif
} -
Use the
#ifdefand#endifblocks:BOOL IsValid (MyType *p) {
// do something
#ifdef _DEBUG
TestIsValid();
#endif
}thank you, walder. but in my "TestIsValid()", I will call "IsValid()", I'm afraid this will cause an infinite recurrent problem. the other problem is, "IsValid( )" is called quite a few times in the application, I don't want to run the unit test code all the time. Is there a way to get something like a shell window, and I just type in "TestIsValid" to get it run? Thanks!
-
thank you, walder. but in my "TestIsValid()", I will call "IsValid()", I'm afraid this will cause an infinite recurrent problem. the other problem is, "IsValid( )" is called quite a few times in the application, I don't want to run the unit test code all the time. Is there a way to get something like a shell window, and I just type in "TestIsValid" to get it run? Thanks!
deport your unit tests into their own project into the solution, with a reference to the sources to be tested.
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
-
deport your unit tests into their own project into the solution, with a reference to the sources to be tested.
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
-
thank you, walder. but in my "TestIsValid()", I will call "IsValid()", I'm afraid this will cause an infinite recurrent problem. the other problem is, "IsValid( )" is called quite a few times in the application, I don't want to run the unit test code all the time. Is there a way to get something like a shell window, and I just type in "TestIsValid" to get it run? Thanks!
Sorry, I'm having a difficult time trying to understand what you are doing? It sounds like you have a function
TestIsValid()which in turn callsIsValid()which in turn callsTestIsValid(), and so on... Perhaps you could show me some code. You dont have to use the only theDEBUGdefinition, you can create your own#ifdef DEBUG
#ifdef MYFUNC_1
// do something
#endif
#endif -
Sorry, I'm having a difficult time trying to understand what you are doing? It sounds like you have a function
TestIsValid()which in turn callsIsValid()which in turn callsTestIsValid(), and so on... Perhaps you could show me some code. You dont have to use the only theDEBUGdefinition, you can create your own#ifdef DEBUG
#ifdef MYFUNC_1
// do something
#endif
#endifdo you know what unit tests are for ? they are written to verify that management rules are correctly implemented. for this, unit tests can be ran, but they mustn't be included in the main project as their code is only for the development purpose...
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
-
Sorry, I'm having a difficult time trying to understand what you are doing? It sounds like you have a function
TestIsValid()which in turn callsIsValid()which in turn callsTestIsValid(), and so on... Perhaps you could show me some code. You dont have to use the only theDEBUGdefinition, you can create your own#ifdef DEBUG
#ifdef MYFUNC_1
// do something
#endif
#endifhere's the sample code:
BOOL IsValid(MyType *p) { /* test whether MyType *p is valid. * if valid, return TRUE. * return FALSE otherwise */ ..... } void TestIsValid () { MyType a; BOOL bRet; bRet = IsValid (&a); printf ("IsValid( ) returns %d.\n", bRet); }So I don't see I can use what you recommended first as:BOOL IsValid (MyType *p) { ... #ifdef _DEBUG TestIsValid(); #endif }I hope I made myself clear this time. -
do you know what unit tests are for ? they are written to verify that management rules are correctly implemented. for this, unit tests can be ran, but they mustn't be included in the main project as their code is only for the development purpose...
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
toxcct wrote:
for this, unit tests can be ran, but they mustn't be included in the main project as their code is only for the development purpose
That is, of course, unless you are following one of the Agile Design models. In almost all of those paradigms, the unit test cases should accompany the source code, but won't get linked into the final application (generally, you have a separate unit-test project file that has a main.cpp that simply calls all your unit tests and reports the results).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
here's the sample code:
BOOL IsValid(MyType *p) { /* test whether MyType *p is valid. * if valid, return TRUE. * return FALSE otherwise */ ..... } void TestIsValid () { MyType a; BOOL bRet; bRet = IsValid (&a); printf ("IsValid( ) returns %d.\n", bRet); }So I don't see I can use what you recommended first as:BOOL IsValid (MyType *p) { ... #ifdef _DEBUG TestIsValid(); #endif }I hope I made myself clear this time.So place it in the other function:
void TestIsValid()
{
MyType a;
BOOL bRet = false;
#ifdef _DEBUG
bRet = IsValid (&a);
printf ("IsValid( ) returns %d.\n", bRet);
#endif
} -
do you know what unit tests are for ? they are written to verify that management rules are correctly implemented. for this, unit tests can be ran, but they mustn't be included in the main project as their code is only for the development purpose...
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
To be honest I have never heard of them, but I guess they are something similar to the
ASSERT()macro, only with more functionality. -
To be honest I have never heard of them, but I guess they are something similar to the
ASSERT()macro, only with more functionality.waldermort wrote:
To be honest I have never heard of them
You have never heard of unit tests?
waldermort wrote:
similar to the ASSERT() macro, only with more functionality.
Not really. Unit tests isolate a module and do a thorough diagnostic on it. That is, a good unit test will test all the public methods of a module to make sure they give the desired results.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
waldermort wrote:
To be honest I have never heard of them
You have never heard of unit tests?
waldermort wrote:
similar to the ASSERT() macro, only with more functionality.
Not really. Unit tests isolate a module and do a thorough diagnostic on it. That is, a good unit test will test all the public methods of a module to make sure they give the desired results.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
Zac Howland wrote:
You have never heard of unit tests?
That surprises you? :cool:
led mike
It does surprise me a bit. That is one of the topics that should be required for any computer science/computer engineering curiculum, but I guess some places don't think you need to test your work :-P
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
It does surprise me a bit. That is one of the topics that should be required for any computer science/computer engineering curiculum, but I guess some places don't think you need to test your work :-P
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac