Home > Archive > Extreme Programming > July 2004 > CPPUnit Query
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| Hi All,
I am trying to use CPPUnit for doing some Automation Testing.
Can I have a COM DLL which contains test cases and which is linking
dynamically to CPPUnit.
I will be writing a client of this COM DLL to run test cases by
passing paramters for the cases and get result in XML format.
Is this feasible ?
Don't know if it sounds absurd.. but please help me...
Regards
Raj
| |
|
| Raj wrote:
> I am trying to use CPPUnit for doing some Automation Testing.
>
> Can I have a COM DLL which contains test cases and which is linking
> dynamically to CPPUnit.
> I will be writing a client of this COM DLL to run test cases by
> passing paramters for the cases and get result in XML format.
>
> Is this feasible ?
> Don't know if it sounds absurd.. but please help me...
The ideal, when you develop by testing, is you hit the One Test Button after
the fewest possible edits - say 10 at the most.
Under Visual Studio, you can compile a testing program and a COM at the same
time, if you put both their DSPs into one Workspace (.DSW), and declare a
dependency.
Then you import the COM into the test rig using #import
<mypath/Debug/mycom.dll>. That generates a C++ wrapper object that is much
easier to use than raw OLE-style COM stuff was.
(An upcoming book on TDD will cover many of these topics, but it won't be
out before your deadline!;)
However, TDD is white-box. You should also have tests that call the COM
object's unpublished support methods directly. So keep much of the COM
class's source free of the COM mechanics, and link their source files
directly to your test rig.
Tell us how this works out.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
|
| Hi Philip,
Thanks for your comments..
But honestly I did not get what all you said as I am very new to
testing.
Let me rephrase, what I am trying to do.
I want to write an automated testing tool using CPPUnit.
This will have two components. First component will have GUI, it will
have the data to be tested.
This will be a C++ application.
Second component will be a COM DLL in C++. This DLL will be containing
all the test cases and will be linked dynamically to CPPUnit.
In the CPPUnitTestApp example in CPPUnit, it uses MFC application as a
container for test cases and link to CPPUnit statically.
Instead of MFC Application, I want to use a COM DLL (if not possible
will try Extension DLL).
All the test cases will get required parameters from the first
components which it will pass when it calls second component.
All these test cases contain some function calls to few COM DLLs to
test some functionality.
I will be using only test framework of CPPUnit, basically XMLOutputter
and TestRunner and not the GUI.
I hope I have cleared it more..
My concern is, is this feasible ?
Regards
Raj
"Phlip" <phlip_cpp@yahoo.com> wrote in message news:<%6bOc.3572$Lj3.2927@newssvr32.news.prodigy.com>...
> Raj wrote:
>
>
> The ideal, when you develop by testing, is you hit the One Test Button after
> the fewest possible edits - say 10 at the most.
>
> Under Visual Studio, you can compile a testing program and a COM at the same
> time, if you put both their DSPs into one Workspace (.DSW), and declare a
> dependency.
>
> Then you import the COM into the test rig using #import
> <mypath/Debug/mycom.dll>. That generates a C++ wrapper object that is much
> easier to use than raw OLE-style COM stuff was.
>
> (An upcoming book on TDD will cover many of these topics, but it won't be
> out before your deadline!;)
>
> However, TDD is white-box. You should also have tests that call the COM
> object's unpublished support methods directly. So keep much of the COM
> class's source free of the COM mechanics, and link their source files
> directly to your test rig.
>
> Tell us how this works out.
| |
|
| Raj wrote:
> Thanks for your comments..
> But honestly I did not get what all you said as I am very new to
> testing.
No prob. I neglected to read your post first.
> Let me rephrase, what I am trying to do.
>
> I want to write an automated testing tool using CPPUnit.
You might mean an "Acceptance Test Framework". That's a literate environment
to author test resources as database tables, and execute them.
> This will have two components. First component will have GUI, it will
> have the data to be tested.
> This will be a C++ application.
>
> Second component will be a COM DLL in C++. This DLL will be containing
> all the test cases and will be linked dynamically to CPPUnit.
I don't understand this part: What is your usage scenario. Say, "the tester
does X, then the programmer does Y, then the tester does Z."
> In the CPPUnitTestApp example in CPPUnit, it uses MFC application as a
> container for test cases and link to CPPUnit statically.
> Instead of MFC Application, I want to use a COM DLL (if not possible
> will try Extension DLL).
Switch the libraries to ATL and WTL. MFC sucks, and sucks extra for COM.
> All the test cases will get required parameters from the first
> components which it will pass when it calls second component.
> All these test cases contain some function calls to few COM DLLs to
> test some functionality.
>
> I will be using only test framework of CPPUnit, basically XMLOutputter
> and TestRunner and not the GUI.
>
> I hope I have cleared it more..
>
> My concern is, is this feasible ?
That depends on the usage scenario. Technically it's feasible.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
|
|
|
|
|