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

[Tobias Boege]

On Wed, 26 Feb 2020, Benoît Minisini wrote:
> > 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.
> 

Would it be so bad if the interpreter loaded all test modules upfront
and passed them all? Certainly that's a waste if only one module was
needed, but does it matter? I have no idea how costly loading a class
normally is.

Or yes, you could provide this Application.Tests property as a virtual
collection which fetches test modules on demand...

> > 
> > 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.
> 

That's just as good with me.

Regards,
Tobias

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk