[Gambas-user] Using test interface for scripter testing

[Brian G]

I liked your last paragraph!

Lets see what falls out...


----- Original Message -----
From: "Tobias Boege" <taboege at gmail.com>
To: "Gambas mailing list" <user at lists.gambas-basic.org>
Sent: Sunday, June 28, 2020 4:36:13 AM
Subject: Re: [Gambas-user] Using test interface for scripter testing

On Sun, 28 Jun 2020, Brian G wrote:
> > I have been implementing a test framework for scripter, and some of my own apps from my experience so far these are some things I have found difficult and thus the suggestions. 
> > Please understand that I really do appreciate the work that has been done and and the functionality it provides. This is a bit long! 
> > I would like to suggest the following be added to test framework if possible. It would make unit testing of the application and its modules a little simpler. 
> > 
> > Assert.Startup("startupModExpected") ' used to verify you have not forgotten to set to real startup ... lol 
> > Assert.Exported("namelist",......... ) ' list of expected exported modules and classes fails if don't match 
> > Assert.Interface("modOrClass", "interfaceFuncOrVarsOrProperty".....) ' test exported mods or classes that the interface is correct ie public functions and variables exposed, returns fail if they don't match. 
> > 

>>> The reason why I say these look special is that _normally_ the compiler
>>> (or when late-bound, the interpreter) does these checks for you already.

I don't want to validate any other libs or module's interfaces.

I am trying to verify that for the Component or shared library I am writing,
the library or Component the test module exists in, meets the required specification.

i.e. the interface to the component/Lib tested has not been changed or modified
and that all the classes and Public interfaces expected are defined and exported.

So if someone works on the component and changes the interface or forgets to export the class etc.
the test will fail. This comes Back somewhat to being a model interface
I could write 

Assert.Startup("startupModExpected") ' used to verify you have not forgotten to set to real startup ... lol 
Assert.Exported("namelist",......... ) ' list of expected exported modules and classes fails if don't match 
Assert.Interface("modOrClass", "interfaceFuncOrVarsOrProperty".....) ' test exported mods or classes that the interface is correct ie public functions and variables exposed, returns 

And if theses were correctly implemented it would pass, 
and during maintenance work, if someone changes it, it will fail.


I guess everything can be coded by the user, but from a selling it to users standpoint
Some things made easy and clear are much better sales tools.


It's a matter of perception, not need.


>>> As a general rule of thumb: yes!

>>> We've struggled against time (among others) to get gb.test to a stable state
>>> for the 3.15 release. There are definitely things to improve which we decided
>>> to do as part of the 3.15+ lifecycle(s) while users get accustomed to using
>>> gb.test and point out shortcomings.

>>> You are the first to do so, but I think the fact that you praise the efforts
>>> so far and propose additions only is a very good sign for the 3.15 release.

>>> Your ideas, except the absolutely easiest that we all agree are useful and
>>> well-designed, are unlikely to go into master now and hence into 3.15.0.
>>> GUI testing, for example, would likely require an addon component gb.test.gui
>>> (perhaps already a misleading name!) so as to not put a GUI dependency on
>>> gb.test.

>>> So, after 3.15.0 is released with a stable base gb.test, I would ask everyone
>>> to try out gb.test and the IDE (and gbt3 if it still exists), compile your
>>> own additions to Assert and Test that you often need in user libraries and
>>> share them.

Great Plan!

Regards,
Tobias

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk
p.s. I have been binge watching monk this last weekend... lol

----[ http://gambaswiki.org/wiki/doc/netiquette ]----