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

[Tobias Boege]

On Fri, 06 Mar 2020, Christof Thalhofer wrote:
> Am 06.03.20 um 09:52 schrieb Benoît Minisini:
> 
> > Is there a reason why 'gb.test.tap' is compiled before 'gb.test'? (see 
> > 'comp/src/order')
> > 
> > It seems not logical, unless these two components are completely 
> > independent?
> 

I'm just coming back, slowly, from vacation and a flu. Please bear with me.

gb.test.tap is meant to be common code for printing and parsing TAP. It is
what gb.test should use so that gb.test.tap is a transitive dependency of
every project in "test mode". There will be a global Assert object that the
test code and gb.test can use together to print a coherent TAP stream.
This is why gb.test.tap must be compiled before gb.test -- it is a dependency.

Furthermore, gbt3 and the IDE should use gb.test.tap for parsing TAP output
from test programs.

> We will have to rethink dependencies ...
> (please forget my Flowchart)
> 
> This is what I think now, IMO:
> 
> * gb.test should contain Assert.
> 
> * Assert should be a module not a class
>   (we do not need an object being Assert).
> 

Ok, why not.

> * gb.test.tap should contain gb.test as component
>   and should provide its Unittest() like that:
> 
>   Unittest(Tests as String, Optional Values ... )
> 
>   The variable "Tests" is a comma separated string
>   of testmodules and testmethods.
> 
> Because:
> 
> Maybe we later want to have another output module for testing instead of
> gb.test.tap? Imagine things like that:
> 
> gb.test.db -> writes test output into a database
> gb.test.log -> hands over to syslog
> gb.test.monitor -> hands over to a monitoring system
> gb.test.csv -> writes tests output to a csv file
> 
> Or someone can write it's own testing system.
> 

How does turning around the dependency I described above achieve this?
gb.test.tap is a generic component for reading and writing TAP. It is
only tangentially related to testing in Gambas. gb.test.tap is an
implementation of TAP just like gb.web contains an implementation
of JSON. gb.test on the other hand is the testing framework component
shipped with Gambas, it should organize, setup and drive the testing.
People can write their own testing framework (potentially), but gb.test
is the one officially provided by Gambas.

If you want gb.test not to output TAP but CSV files, then make gb.test
recognize some kind of configuration, maybe via environment variables,
to load instead of gb.test.tap the gb.test.csv component. That component
must provide an Assert module with the same interface as gb.test.tap.
Then that Assert module can do with the assertions whatever it wants.
If Assert becomes part of gb.test, how will you handle the conversion
of high-level assertions to different output formats?

IMO, gb.test may or may not use gb.test.tap, but gb.test.tap should not
depend on gb.test.

Regards,
Tobias

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gambas-basic.org/pipermail/user/attachments/20200310/ca9106d9/attachment.sig>