[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.vb.general.discussion

Unit Testing / TDD in VB6

Jason Keats

7/21/2011 10:07:00 AM

Is there anyone here using or able to recommend a unit testing tool?

I found the following, but haven't yet had time to try them.

Simply VB Unit 3.0
http://simplyvbunit.source...

VB Lite Unit 1.2.5
http://vb-lite-unit.source...

vbUnitFree 0.6
http://vbunitfree.source...

TinyUnit
http://www.w-p.dds.nl/ti...

COMUnit
http://comunit.source...

VB Unit / vbUnit3
http://www.v...


1 Answer

Schmidt

8/17/2011 4:22:00 PM

0

Am 21.07.2011 12:06, schrieb Jason Keats:

[different UnitTest-Tools for COM]

I'm perhaps a bit late, so this is thought not as
a direct-reply, but more as a "Basics of TDD"-post
"for the group-archive" ... Was recently stumbling over
something, which encouraged me, to try Test-Driven-
Development (TDD) "in Dojo-mode" <g>, following the
simple and interesting "Kata" from this site here:
http://osherove.com/t...

There are some nice Videos for this small example
(for a lot of different languages) - so, in case you're
interested, please follow some of these "dev-screens"
(maybe skip some boring parts - and wait 1-2minutes
on the more interesting ones), but you'll definitely get
a good first impression, regarding "what's it all about".
On average (according to the vids), one gets the
tests (and the matching implementation) finished
after about 20-30minutes (most devs/vids complete
the Kata only up to Point 5).

I wrote a small and simple (but already generic) Method-
Tester-Dll for it (some Mini-UnitTest-Tool if you want),
to be able, to code this example in a TDD-conform-fashion -
reflecting (as seen similarly in the vids) the TestOutput
then within the VB6-IDEs DirectWindow.

Here's my commented (and final) code for the "Kata-Project",
passing all the tests (ClassTest.vbp), as well as the
Dll-Project for the small UnitTest-Dll (MethodTester.vbp
and MethodTester.dll). In case you don't want to register
MethodTester.dll, please start the Group: _Test.vbg.
The UnitTest-Dll depends (in case you want to use it in
*.vbg IDE mode - or want to compile it yourself) on
Eduardo Morcillos OleLib.tlb (VB6s CallByName-Function
was not transporting the Error-Infos correctly).
www.datenhaus.de/Downloads/SimpleTDDhelper.zip

If you want to get the "right feeling" (on what it does to
your coding-style and final result... really worth it IMO),
then you shouldn't look all too long on my concrete
implementation in cCalc - maybe just ensure, that
the *.vbg ... or (when registering MethodTester.dll)
that the ClassTest.vbp works at all (it should print two
appropriate "Success"-Messages in the Debug-Window) -
and then simply delete the Content of cCalc - as well
as the .Test-call-Block in Sub Main() for this Class
(after studying those calls mayhap somewhat longer, to
get familiar with the .Test-call-conventions and its
Parameters ... IsEqualTo, IsErrNumber & Co.).

I'd be curious, with what code you'll end up -
when accomplished in a "test-driven-manner".


My personal conclusion in advance (would of course
also be interested about your summary, and if the whole
TDD-thingy "could be something" for you - or not):

IMO it's not the worst approach to tackle "clean coded Apps",
especially when working in a team, or having a large,
complex project (with a lot of need for more cleanup -
or "maintainability")...
But after playing around with it (yes, it *does* make fun ;-) -
I think - with regards to "over-all-coding-efficiency" -
that the VB6-IDE with its Edit/Continue behaviour and
fast Compile-Times, can compensate quite a bit (we are
spoiled).
One is a bit faster without TDD, especially when there
are a few years of experience to resort to (think,
that applies to most of the members of this group in
the meantime).

But then (on the other hand) - although being a bit
faster when in "normal-test-mode" as e.g.:
"write it up directly, *followed* by appropriate
tests using E&C and the usual debugging-techniques"
You still end up *without* any "decently written tests".

Maybe the right mix is it then (as always).

TDD (when done "by the book") recommends incremental
and pretty small steps - and that's the thing which goes
a bit against the "experience-thingy" I've already
mentioned.
So, when doing TDD, there's (IMO) the danger, that one ends
up with a well-working solution which covers all your tests -
but whilst developing it in these "fine-granular-steps"
one can lose himself a bit in this quite scematic process,
rewriting (refactoring) all these "intermediate solutions"
more often - than ones experience (and a little bit of
"forward-thinking" in larger-steps) would have allowed,
when working in "normal mode".


So, yeah - hoping a few of you try the Kata - and post
their conclusions here as well.

Olaf