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

[Christof Thalhofer]

Hi Tobi,

Am 10.03.20 um 17:34 schrieb Tobias Boege:

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

Sorry for my rant this morning. I would have preferred if we first had
got the job done in the branch gb.test.tap before integrating it into
master.

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

Assert should not be in gb.test.tap, because if one wants to create
another output component (gb.test.log, gb.test.db ...) all Assertions
would have to be duplicated (and tested!!!) there, which makes no sense IMO.

Look: If gb.test.tap or gb.test.db would have an interface called "Ok"
which is called by Assert.xyz, that would be enough. This Ok(Result as
Boolean, Message as String) can do anything, count tests, print to
Stdout or store into a Db, what you want...

>> * gb.test should contain Assert.
>>
>> * Assert should be a module not a class
>>   (we do not need an object being Assert).
>
> Ok, why not.

Ok, ahm ... what? A few lines later you write the opposite. *

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

* At this point I disagree.

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

What are "high-level assertions"? Can you give me an example?

If someone wants to write own assertions elsewhere Assert in gb.test can
easily been extended by creating an own Assert class which automatically
inherits an existing Assert in gb.test.

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

I agree.

Hmm ok, but please write a piece of code that does what the old gb.test did:

* Test itself and let us step through the assertions while debugging it.
This is important! Assertions can be buggy, they look simple but it is a
testing system that tests a lot of other projects in future so it has to
be rock stable!

* Output the result of a single assertion immediately, not after all
tests are done.

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/20200310/922e2d06/attachment-0001.sig>