[Gambas-user] Coming back to gb.test

[Benoît Minisini]

Le 07/05/2020 à 09:59, Tobias Boege a écrit :
> On Thu, 07 May 2020, Christof Thalhofer wrote:
>> Am 07.05.20 um 08:25 schrieb Benoît Minisini:
>>
>>> If a class needs to be exported (so that the component works), but
>>> should not be used by the final user, I prefix the class name with an
>>> underscore.
>>
>> Ok, I think we'll have to do that for TestAssertion and TapContext.
>>
>> AFAIK Tap and TestStats must not be exported.
>>
>> Tobi? Are you watching?
>>
> 
> TestAssertion and TapContext objects are definitely returned by public
> methods. It would be nice if autocompletion in the IDE works for those,
> but otherwise they can be hidden, as they are only consumed by users.
> 
> I think it would not break anything to unexport TapParser and TapPrinter,
> leaving only the high-level interfaces of Assert / Test (TAP out) and
> TestHarness (TAP in). With this done, there pretty much no reason to
> export TapContext anymore either, the only two references being in
> TapPrinter.Session and Test.Session, both for internal usage by gb.test.
> This eliminates almost every mention of TAP in the component's interface.
> 
> The Tap class contains constants that are referred to by TestAssertion,
> maybe the constants can be moved into TestAssertion (whose existence is
> the result of a very recent refactoring). Then Tap can go as well.
> 
> TestStats is supposed to be the summary of a test run produced by the
> TestHarness class. It was written so that a TAP parser, like soon the
> IDE, just has to pipe `gbx3 -T ...` into TestHarness and get out an
> object representation of the test result (plus ability to zoom in as
> far as to individual assertions). It can be hidden for the same reason
> as TestAssertion and TapContext but should remain exported.
> 
> Should I attempt to do these things?

Yep.

> 
> As for the "allocations non-freed" warning: that's a lot of allocations.
> The data structures that keep testing information during the test run
> (TestAssertion and TapContext) are strictly hierarchical, so I don't think
> there is a real circular reference at this point. The message only appears
> in the BailOut test, too.
> 
> Benoît: is this expected given that there is a hard `Quit 1` deep down
> the call stack of a method from an object which references lots of data?
> I imagine that the object is referenced while one of its methods execute
> and when that execution results in a Quit, the object cannot be freed
> while the interpreter shuts down?

That makes sense. When I have time, I will check what happens exactly.

Regards,

-- 
Benoît Minisini