[Gambas-user] New component gb.test

[Tobias Boege]

On Mon, 21 May 2018, Christof Thalhofer wrote:
> 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. ;-)
> 

So, after catching up on all the mail that arrived while I was writing mine,
it seems like we are on the same page after all.

TAP is a good output format, running tests in a separate process is a good
idea and it has the side effect of ensuring separation of test and GUI.
Viewing tests as mere blackbox scripts is not convenient enough, at least
some of them need a more structured interface and calling convention.

Deleting the gb.deg.unittest classes was a faux pas. I had a big amount of
code that would have taken /me/ more time to understand and port properly
than I had, not because of TAP but because of it running in a separate process,
and I wanted to upload a clean first gb.test to the official tree quickly as
there was demand, so I made tabula rasa. But I hope for the gb.deg.unittest
experts to turn up when time permits and do the porting, or report insuffi-
ciencies in the two Good Things above which prevent that from being done.

When saying this I should also say that I realise now that it wasn't friendly
to give up on studying your code to integrate my changes but instead to
effectively force you (or someone else) to rebuild yours on top of mine.
Of course it is my opinion that my own code is vastly easier to understand
than anyone else's :-)

Regards,
Tobi

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