[Gambas-user] gb.test

[Christof Thalhofer]

Am 23.02.20 um 17:16 schrieb Tobias Boege:
> On Sun, 23 Feb 2020, Christof Thalhofer wrote:
>> If you want to join – my idea was like that: [...]
>>
>> ---------------------------------------------------------------
>>
>> I myself currently try to write gbt3.gambas in app/src/gbt3, which will
>> be able to test a project at the commandline, prints out TAP and can be
>> used for automatic testing on deployment.
>>
> 
> The only thing I can do is to fix up and commit my gb.test.tap component,
> which provides you with TAP printing and parsing classes. There is nothing
> in there for organizing and running tests, it just deals with the TAP text
> format and protocol. With it you can factor out TAP printing from the
> tests and the parsing from your gbt3 harness or a potential future IDE
> harness which does green/gray/red LED toggling. In any case, it is just
> an implementation of both parties of a protocol in a reusable component,
> independent of the act of testing Gambas projects (which is gb.test's
> goal).
> 
> Looking at your code, the Assert.module is part of gb.test.tap, as it
> converts runtime assertions into TAP, and your Track.module is part of
> the TAP producer / consumer state as well (it seems to serve both parties
> in gb.test). It would also affect every place in the code where you Print
> some TAP inline, for example in UnitTest.class. So using the gb.test.tap
> component would involve some refactoring of gb.test, which really just
> consists of deleting code.
> 
> I haven't grokked yet how you implement fixtures and cherry-picking tests
> to run, but I have a feeling that the common "subtests" extension, which
> is implemented in gb.test.tap already, provides a way to model this nicely
> with TAP -- namely by making each *test method* into its own subtest.
> The test planner, which selects fixtures and test methods, can then even
> print the correct "plan" line at the very beginning.
> 
> Those are the two things that have been on my mind about this. But first
> things first. I'll put up a merge request for gb.test.tap as soon as the
> last TODOs are eliminated, then we'll take it from there.

Testing, cherry-picking, fixture and TAP printing is already done in
gb.test (maybe it can be done better). What is needed now is the parser
and integration into the IDE.

If you would like to refactor gb.test and integrate your own code to
make it better, feel free to do that, but please create a separate
branch for that, so that we can compare afterwards. And please don't
break things. gb.test tests itself, these tests are developed for more
than two years now and cover most of it's behavior. There are a lot of
things which were quite difficult, especially how it handles and reports
errors, crashes and so on.

In the meantime I have learned that neither of us invests much energy in
the efforts to read and analyze the code of the other. ;-)

This brought us earlier into the situation that code in gb.test.tap
fulfilled the same tasks as code in gb.test (which already existed
before), only different, but incompatible and difficult to combine. At
least that was my feeling. We have clashed on this issue before, so I
would very much like to avoid that in the future. I hope you think the same.

Please don't get me wrong, I find some code you write incredibly
elegant, other is difficult for me to understand and I don't always have
time to bust in. I think we all feel that way.

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/20200223/4db49ea5/attachment.sig>