[Gambas-user] gb.test

[Benoît Minisini]

Le 15/01/2020 à 00:21, Christof Thalhofer a écrit :
> Hello Benoît,
> 
> Am 05.01.20 um 11:20 I wrote:
> 
>> *But this is not the main problem.*
>>
>> The main problem in my opinion is that Class.Load(sName) in
>> GetAllTestContainerNames only works if the testclasses are exported and
>> so these are visible and callable later on when the project is in
>> production. I don't like that.
>>
>> There IMO we need a new form of class a la classname.test which is
>> handled by the interpreter/compiler in a different way.
>>
>> My idea was, that not the IDE tests but the executable itself is able to
>> test itself when compiled with debugging symbols and called in a special
>> way.
>>
>> If you create and call unittesthelloworld.gambas you can see what I mean.
> 
> Or can we create something like a "gbt3" executable that finds all tests
> in a project and executes them?
> 
> I need that in future for automatic testing of Gambas programs before
> deployment.
> 
> Alles Gute
> 
> Christof Thalhofer
> 

I'd prefer adding an option to the 'gbx3' interpreter that make it run 
all the tests through a static method somewhere in 'gb.test'.

To recognize what are the test classes, is it mandatory to make them 
inherit a specific parent class?

Because we can assume that a special directory (for example 
'.src/.test') in the project will store all the tests, and I can make 
special support for that directory in the IDE (The '.test' directory 
will become a special folder in the project tree).

Then the compiler will be able to detect that directory, compile the 
files inside as normal classes, but at the end make a list of all test 
classes in a dedicated file in the project root directory ('.test' again?).

That way, the 'gb.test' component will just have to open that text file 
to know the name of each test classes, and run what it should run in it.

Another different idea would be creating a new source file extension 
('*.test') that would represent a module whose code is the test for the 
real source file having the same name.

In that case, a test has to be a module, not a class, a form, or 
anything else.

I really like that idea because it makes the structure of the tests 
similar to the structure of the source code, and allows to check things 
like: is the source code newer that the test code? But maybe it is not 
flexible enough for special test cases, I dunno.

What do you think about all that?

-- 
Benoît Minisini