[Gambas-user] New component gb.test

Christof Thalhofer chrisml at deganius.de
Mon May 21 22:08:29 CEST 2018


Hi Tobi,

Am 21.05.2018 um 18:14 schrieb Tobias Boege:

>> Shouldn't it?
>>
> 
> Definitely. The problem is that
> 
>   Exec ["gbx3", "-s", Test, Project] To sOutput
> 
> returns me an empty sOutput in this case, so the parser gets no note of the
> passed tests at all. I don't know why but it has been a TODO item (shortly
> above that line) to not buffer all the output into a String variable anyway
> but to use the Process object as a stream. Maybe then I'll get the lines
> which were printed before the crash, too. Someone should reproduce that
> behaviour with "Exec To stringvar" and file a bug as well...
> 
> While I'm at it, I should also capture stderr and convert it into diagnostic
> messages. Doing that in Gambas always requires this weird mix of event-driven
> and synchronous programming, but I just saw that there is a Process.Wait()
> method, which should come in handy.

I am thinking a lot about your approach.

The idea of letting the interpreter do the work of testing as a separate
process is brilliant, but the idea of the Main() method in my eyes is not.

As I told you as I spoke about fixtures I found out that I need the
fixtures to create different environments for different testmethods or
different testsuites.

Testsuites can be combinations of testmethods arranged in random order,
for example for development or production.

Yes that can all be done inside one module with a Main() method but this
is not really flexible in my eyes. It cannot execute testmethods
independently. And the really important thing is, that a crash of one
test must not destroy other tests.

I do a lot of testing with the old gb.deg.unittest and I had to invest a
lot of time to make it work and it is "tested" in the sense that it
tests a lot of production code in my firm, now for years, so it works!
It also can handle Gambas Errors and Failures and report them.

The thing, why we started rewriting the code, was, that Benoît mentioned
that GUI and testcode are not independent, and that the testcode should
output sth standardized which could be eaten by GUI or sth other.

There came the idea of TAP. But TAP as output format!

So I think you first should throw a little of your great brain on the
existing code instead of throwing it away completely and writing your own.

You wrote:

> In general, the component is currently modeled after perl's test facilities.
> Not because I think it's the best option for Gambas but because I didn't
> have to think up my own thing before getting something remotely usable.
> So feel free to change it, but only for the better 

I think the better is the code in gb.deg.unittest. ;-)

Alles Gute

Christof Thalhofer

-- 
Dies ist keine Signatur

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20180521/34837c8f/attachment.sig>


More information about the User mailing list