[Gambas-user] gb.test

Christof Thalhofer chrisml at deganius.de
Sat Feb 22 21:28:32 CET 2020


Am 22.02.20 um 16:04 schrieb Benoît Minisini:

>> If I add support for test modules in the IDE, would you use it first?

Sure!

>> The idea is that every source file with 'test' extension is a module, 
>> except that the compiler will generate a list of these modules in a 
>> file, so that the interpreter and/or the 'gb.test' component 
>> automatically get all test classes.
>>
>> Of course, it means that a test module cannot have the same name as any 
>> other source file.
> 
> OK, support for test modules has been added in the compiler, the 
> archiver and the development environment in the last commit.

Ok very cool!!

> Now we should link that to how gb.test works (if there is something to 
> do), and add an option to the interpreter that tells him to run the 
> tests (some of them, all of them...).
> 
> That option can just be a string that is sent to an hardcoded 'gb.test' 
> method that will interpret it and do the job.

Ok, I'll look at it soon!

> Is it possible to add to the IDE a button that run the tests 

Concerning the IDE I think it would be necessary to use a F-Key
primarily (I would prefer F4) because if you do test driven programming
you will hit it instead of F5 and as often as F5. A button would be
optional (and only used by notorious mousejockeys).

> and display 
> the result in a nice GUI, provided that the text returned by the test is 
> in a standard format? 

The output of gb.test is a standard format. It is TAP.
http://testanything.org/

*gb.test is a TAP producer*

We later can be member of this illustrious list of producers:
http://testanything.org/producers.html

For GUI we have to write a so called *TAP consumer* which is able to
parse and display the output. But theoretically every other TAP consumer
could be used. Even if it is written in another language.

> (I think then that the test output cannot be sent 
> to the standard output or the error output of the process).

Sorry, but IMO this is a must! Think of automatic testing:

Think of testing, compiling, deployment of Gambas programs in Continuous
Integration (CI) environments later where no person sits there and grabs
the mouse to click a test button or hit F4 or have a look at the GUI.

Think of this scenario: If you would like to push the new version of
your Gambas program to the website with a shell script, maybe you would
like to do this as a Git hook. If you push the code to Git master the
shell script is invoked, which tests (imagine gbt3), compiles (gbc3),
packes (gba3) and then rsyncs the program to the website. This procedure
is stopped if a test failed, and you are notified by a mail which
contains the failure text.

This can only be done if a "gbt3 projectxyz" produces TAP as standard
output.

I am not sure how this can be realized, but meanwhile I think we should
create gbt3 which could contain the execution part of gb.test which is
Unittest.Main() and some necessary classes.

The IDE could (after hit F4) compile the project, then invoke gbt3, grab
the TAP output, parse and display it.

But gbt3 could be used independently of the IDE, as gbc3, gba3 and so on.

What do you think about it?

Alles Gute

Christof Thalhofer

-- 
Dies ist keine Signatur

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gambas-basic.org/pipermail/user/attachments/20200222/897f7dee/attachment.sig>


More information about the User mailing list