[Gambas-user] Integrate unittest component to Gambas

[Tobias Boege]

On Mon, 23 Apr 2018, Christof Thalhofer wrote:
> > I forked your repository
> > and started with the rewrite [1]. This is a multistage process:
> > 
> >   [X] Write low-level TAP printer and parser.
> >   [ ] Make corresponding higher-level interfaces akin to Test::More and
> >       Test::Harness in perl, but Gambas-y.
> >   [ ] Port the rest of the component to the TAP classes.
> >   [ ] Of course, write tests. This should include interfacing the component
> >       with other TAP producers and consumers.
> > 
> > Comments welcome. If you want to take any of the above tasks yourself,
> > we'll have to coordinate it.
> 
> Ups .. double work. I did it [x] yesterday in the branch develop.
> 
> https://github.com/Deganius/gb.deg.unittest/tree/develop
> 
> May you first have a look at that? The TAP printer is done. But feel
> free to make it better (or replace it with yours).
> 
> Btw. I got rid of the GUI, it makes no sense at all, IMO. While working
> with the unittest I used it very seldom.
> 

The trap of distributed development. My fault I didn't look through your
other branches. But in the end, it wasn't that much double work. I have
a dedicated class to print TAP, which may be worth including, and also a
TAP parser. Your work touched my point (3) above, too. I can easily rebase
my changes onto yours and consolidate them -- but not before this evening.

If I understood the code at a glance, there is also a bit of a difference
in architecture. You have a TestSuite which contains tests, executes them,
buffers the result and prints it TAP-formatted afterwards, whereas I
imagined (and am used to from perl) that there are many functions which
reduce input data to Booleans (are two strings equal? does this string
match a regex? is this object defined and of a certain type? does this
code not raise an error? are these arrays recursively equal? and so on)
and that Boolean is printed as a TAP "ok/not ok" line, *as you go* through
the tests, in case there is an unhandled error and the test crashes.
The TAP parser will notice such a crash because either not all tests
in the plan "1..N" were executed or the test plan wasn't even printed.
It can still tell you about the tests that *were* run, which tell you
which one crashed.

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk