Home > Archive > Visual Basic Syntax > August 2005 > VB unit-testing tool
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]
| Author |
VB unit-testing tool
|
|
|
| Hi,
I'm posting this across many VB groups, hoping for an answer.
I was looking into employing a VB-unit testing tool for helping in
test-driven development.
I came across-
vbUnit3
comUnit
SimplyVbUnit
I want to know if any of you have used them, and what your experiences have
been.
Any info would be helpful.
Thank you.
| |
| Steve Jorgensen 2005-07-24, 9:04 pm |
| On Fri, 22 Jul 2005 17:05:56 +0530, "a" <a@b.com> wrote:
>Hi,
>
>I'm posting this across many VB groups, hoping for an answer.
>
>I was looking into employing a VB-unit testing tool for helping in
>test-driven development.
>
>I came across-
>vbUnit3
>comUnit
>SimplyVbUnit
>
>I want to know if any of you have used them, and what your experiences have
>been.
>
>Any info would be helpful.
>
>Thank you.
Personally, I've barely touched any of those, but that's because all the ones
that existed when I was first looking (I hadn't found SimplyVbUnit and still
haven't looked at it) had clear obstacles to use for what I was trying to do.
I tried 3 times to write my own, and on the 3rd try, I came up with something
that, though limited in features, really seems to work well for VB and VBA
projects. You can get it from here - http://vb-lite-unit.sourceforge.net/
| |
| Wendell Buckner 2005-07-24, 9:04 pm |
| hello, I just came across this while looking for answers for another problem
I was having... Question: Is there any issues with unit testing COM
components with this tool... Is there a documentation I could look at to see
how this thing works and if it's what I'm looking for?
"Steve Jorgensen" <nospam@nospam.nospam> wrote in message
news:pbt1e1d2ff3c50j51d326v8vkerqoepebt@
4ax.com...
> On Fri, 22 Jul 2005 17:05:56 +0530, "a" <a@b.com> wrote:
>
have[color=darkred]
>
> Personally, I've barely touched any of those, but that's because all the
ones
> that existed when I was first looking (I hadn't found SimplyVbUnit and
still
> haven't looked at it) had clear obstacles to use for what I was trying to
do.
>
> I tried 3 times to write my own, and on the 3rd try, I came up with
something
> that, though limited in features, really seems to work well for VB and VBA
> projects. You can get it from here - http://vb-lite-unit.sourceforge.net/
| |
| Michael Cole 2005-07-24, 9:04 pm |
| a wrote:
> Hi,
>
> I'm posting this across many VB groups, hoping for an answer.
>
> I was looking into employing a VB-unit testing tool for helping in
> test-driven development.
>
> I came across-
> vbUnit3
vbUnit3 is extremely simple to use, but it is only a procedural unit test
app - it does not perfrom any GUI testing.
Haven't seen the others.
--
Regards,
Michael Cole
| |
| Steve Jorgensen 2005-07-25, 4:26 am |
| On Mon, 25 Jul 2005 10:29:21 +1000, "Michael Cole" <noone@hansen.com> wrote:
>a wrote:
>
>vbUnit3 is extremely simple to use, but it is only a procedural unit test
>app - it does not perfrom any GUI testing.
>
>Haven't seen the others.
Unit testing frameworks generally don't test GUI.
If autoamted GUI testing is required, that's generally done by a dedicated
testing team using something like Vermont High Test or other software in that
category.
A friend of mine did implement some pretty impressive close-to-the-GUI
automated testing in MS Access by directly calling event handling procedures
to simulate user actions.
| |
|
|
| Steve Jorgensen 2005-08-03, 10:02 pm |
| On 3 Aug 2005 11:34:21 -0700, ssi@interlog.com wrote:
> http://msdn.microsoft.com/msdnmag/i...er/default.aspx
As far as I'm concerned, that's a great and useful testing tool, but he's
misusing the term unit testing. What he's doing is GUI automation testing
which operates at a completely different level.
| |
| ssi@interlog.com 2005-08-04, 5:07 pm |
| Steve Jorgensen wrote:
> On 3 Aug 2005 11:34:21 -0700, ssi@interlog.com wrote:
>
>
> As far as I'm concerned, that's a great and useful testing tool, but he's
> misusing the term unit testing. What he's doing is GUI automation testing
> which operates at a completely different level.
In my experience/opinion... this "complete" separation of GUI testing
and other code is really pretty arbitrary.
Reading such explanations as I've seen... it's based more on the
inconvenience (in the absence of tools like Tester). And on thinly
disguised abhorrence of all things GUI ... as on any theoretical,
productivity, empirical result basis.
The GUI is in the specs, same as all the other units. Variances from
spec are just as important, just as prone to creep in at any phase.
Given that it is possible to test those variances in similar and
consistent ways, why not?
I wouldn't mind reading any discussion you can point to about that...
--Richard
| |
| Steve Jorgensen 2005-08-04, 10:02 pm |
| On 4 Aug 2005 09:49:08 -0700, ssi@interlog.com wrote:
>Steve Jorgensen wrote:
>
>In my experience/opinion... this "complete" separation of GUI testing
>and other code is really pretty arbitrary.
I said nothing about complete separation of code and GUI testing, but Unit
Testing is something very specific. Unit tests are simple tests of small
units of code in complete isolation. They do not depend on seqence of
operations, so you can run individual tests in isolation at any time, and they
are not resource intensive, so you can run the whole suite after each small
change to make sure there were no unintended side effects.
GUI tests, on the other hand, almost always depend on the order of operations
(and should do so), cannnot be run from within the IDE, take more than a few
seconds to run, etc. They are definitely not unit tests. Of course, a daily
testing plan might include running both the unit tests and automated GUI
tests.
>Reading such explanations as I've seen... it's based more on the
>inconvenience (in the absence of tools like Tester). And on thinly
>disguised abhorrence of all things GUI ... as on any theoretical,
>productivity, empirical result basis.
Well, people who do rigorous testing of their code might not abhor the GUI,
but they recognize that GUI tests are harder to set up, harder to maintain,
and can't be easily run as often as other tests. Thus, it is good to abhor
anything that causes more testing at the GUI layer to be required. Make usit
tests, and under-the-hood functional tests do as much as possible, so there's
little chance of a problem surfacing in the GUI 12 or 24 hours later the next
time it is tested.
>The GUI is in the specs, same as all the other units. Variances from
>spec are just as important, just as prone to creep in at any phase.
No argument there.
>Given that it is possible to test those variances in similar and
>consistent ways, why not?
I did not say nor mean to imply that GUI should not be tested or that GUI
tests are not important. I do, in fact, think such tests are absolutely
crucial. What I am saying is that "unit test" is not a term that describes a
GUI test.
>
>I wouldn't mind reading any discussion you can point to about that...
Read any of the many great books on Test Driven Development - especially Kent
Beck's book.
>
>--Richard
| |
|
| You can also try NUnit v 2.0 : http://www.nunit.org/
SC
"a" wrote:
> Hi,
>
> I'm posting this across many VB groups, hoping for an answer.
>
> I was looking into employing a VB-unit testing tool for helping in
> test-driven development.
>
> I came across-
> vbUnit3
> comUnit
> SimplyVbUnit
>
> I want to know if any of you have used them, and what your experiences have
> been.
>
> Any info would be helpful.
>
> Thank you.
>
>
>
>
>
| |
|
|
| ssi@interlog.com 2005-08-10, 5:08 pm |
| J French wrote:
> On Fri, 5 Aug 2005 18:06:03 -0700, "=?Utf-8?B?U0M=?="
> <SC@discussions.microsoft.com> wrote:
>
>
> Not much use for VB Classic
>
> That is a .NET utility
There is a proprietary thing called VBUnit specifically for VB 6 and
earlier.
But in fact, there's no problem using NUnit with VB Classic, dotnet and
VB6 can be installed on the same machine.
You do have to expose VB6 functions via ActiveX, but it hasn't been a
problem in my experience ... compiling with an ActiveX-exposing class
for testing only.
You get the advantage of the larger support community, real open
source, and having a test base that is already in the next generation:
won't have to be completely rewritten.
Plus, if dotnet is the future, it's a way to become familiar with it.
--Richard
|
|
|
|
|