[Gambas-user] Questions about gb.test and gb.test.tap

[Benoît Minisini]

Le 25/02/2020 à 23:22, Tobias Boege a écrit :
> On Mon, 24 Feb 2020, Benoît Minisini wrote:
>> So I bring the following suggestions:
>>
>> 1) Adding a running test option to the interpreter. (Eventually use '-t' and
>> find another name for the tracing option).
>>
>> 2) The running test option will have an argument that specifies which test
>> modules to run (everything by default).
>>
>> 3) The interpreter in running test mode will not run the startup class, but
>> will load every test module, and will run a global public method in an
>> hardcoded global public class that must be implemented by the 'gb.test'
>> component. For example "Test.Main". It will receive the class objects in
>> argument. This is how it will be able to access non-exported test modules
>> and run them.
>>
>> 4) The '.test' file created by the compiler is still needed. It will be used
>> by the interpreter to find the test modules.
>>
> 
> Talking to Christof today and thinking about this, the suggestions are
> pretty much what we need. The interpreter flag and that it calls a pre-
> defined startup class is quite a nice and uniform solution.
> 
> We were thinking about ways to pass a very fine-grained selection of
> test modules and test methods to run to gb.test and one possibility is
> passing a JSON object with a <test module> to <array of test methods>
> mapping. The interpreter would NOT have to read this JSON string,
> it would just normally pass this string on to the application as part
> of Args, i.e. like this
> 
>    gbx3 -t $PROJECT -- $JSON_GIBBERISH  # or -T if -t is taken
> 
> The JSON format and its handling then is an implementation detail of
> gb.test. Consequently the interpreter would have to pass ALL test
> module Class objects to gb.test's Main and the test framework does
> the actual selection. What do you think about that?

The problem is that only the interpreter can load the test modules. 
'gb.test' can't, as they are not exported.

So I was thinking that -t will receive the list of tests, and that the 
interpreter will load the needed test modules and pass them to 'gb.test' 
startup method.

On the other hand, it is of course more flexible to let 'gb.test' handle 
the test argument. But either the interpreter loads the needed modules 
for it, either it gives 'gb.test' a callback to load them by name.

> 
> There should probably be simpler fallback formats for when you want
> to run all methods in one named module... You should not be required
> to write JSON unless you need maximal flexibility. But that can all
> be delegated to command-line arguments handled by gb.test's Main.
> 

I prefer a basic text format instead of JSON. For example, a list of 
"Class.Method" with "*" meaning everything.

Regards,

-- 
Benoît Minisini