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

[Christof Thalhofer]

Am 10.03.20 um 18:25 schrieb Benoît Minisini:

>> Furthermore, gbt3 and the IDE should use gb.test.tap for parsing TAP output
>> from test programs.
> 
> OK. I still don't really understand why there should be a 'gbt3' program.

The idea of gbt3 was a program that is able to test a project on the
commandline:

gbt3 "testmodule1,testmodule2.testmethod3" ./myproject

It can be called by the IDE but also by other programs (or by hand). I
would use it in my deployment scripts which should stop if testing
reported not ok.

> All that seems logical to me.
> 
> 'gb.test' does the testing, and pass the result of each test to 
> 'gb.test.tap' that prints it in TAP format.

Yes this is what I think also.

> You must agree on the interface the Assert class, and be sure that it is 
> somewhat complete.

Disagree in parts, but later ...

> But I have a few remarks about what I see at the moment:
> 
> 1) ASSERT is already the name of an instruction. But it is not a big 
> deal, as there is no ambiguity between the instruction and the class.

ASSERT was the result of my request in the bugtracker. It is a standard
in programming languages and I also wanted to claim the name. ;-)

I think we can handle that well in the documentation.

> 2) When writing my test modules, I should only call methods in the 
> 'gb.test' component. In other words, I suggest having the Assert class 
> in 'gb.test', and overriding it in 'gb.test.tap'.

Agree, I think the same but I would like to have as much assertions in
gb.test as possible. So they are standard.

Assertions have to be tested well, which is what gb.test itself did
until aa6196323. Unfortunately it is broken since then and I want that
functionality back.

> The Assert class in 'gb.test' could emit nothing, or just an internal 
> format for debugging purpose, or detect that no 'gb.test.*' module has 
> been loaded and abort.

I think in gb.test there should be all standard assertions as they are
now in gb.test.tap so they will not have to be rewritten over and over
in future gb.test.log, gb.test.db and so on.

> The Assert class in 'gb.test.tap' will do the real formatting job.

I disagree that the Assert class playes the role of an interface and it
should also not do any formatting.

If there is an interface in gb.test.tap for example called

"Ok(Result as Boolean, Message as String)" or
"Track(Result as Boolean, Message as String)" or
"Report(Result as Boolean, Message as String)"
... please name it ...

that would be enough, IMO. This interface is mandatory in every gb.test.yxz.

This would make it much easier to write an alternative output component
for gb.test.

> Note that the inheritance thing works only if Assert is a dynamic class 
> with "CREATE STATIC" option, and all its methods being dynamic.

Ah ok.

> Assert methods in 'gb.test' could provide all the common stuff so that 
> there is just printing and formatting in 'gb.test.tap'.

Ok. I see, you think the same.

> 3) Could we rename "UnitTest" into "Test" directly? After all, I may 
> want to do some tests that are not "unit tests".

Yes, for sure.

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/20200311/a8fbb9a4/attachment.sig>