[Gambas-user] New component gb.test

[Adrien Prokopowicz]

Le 23/05/2018 à 00:08, Christof Thalhofer a écrit :
> Am 22.05.2018 um 16:51 schrieb Adrien Prokopowicz:
>> Le 22/05/2018 à 10:57, Christof Thalhofer a écrit :
>>> We should talk about the way how the code should be executed. Maybe we
>>> need some magic here. Can (or should) we hand out the code to a separate
>>> interpreter process? How?
>>
>> Here's a flowchart of how I (ideally) view the different internal parts
>> interacting:
>>
>>                                     +-----------+
>> +--------------+      Starts      |           |
>> |              | +--------------> |           |
>> |  CI System   |                  |  gbtest3  | <--> CLI User
>> |  Gambas IDE  |                  |           |
>> |              | <--------------+ |           |
>> +--------------+   Test Results   +-----------+
>>                      (TAP stream)
>>                                        +     ^
>>                                        |     |  Returns test result
>>                       Starts processes |     |  (Exit code)
>>                          (gbx3 -s …)   |     |  (STDERR for errors)
>>                                        v     +
>>
>>                                  +------------------+
>>                                  |-------------------+
>>                                  ||                  |
>>                                  ||   Test Methods   |
>>                                  ||    (gb.test)     |
>>                                  ++                  |
>>                                   +------------------+
>>
>> (The separation of gbtest3 aside, this flow is quite similar to Tobi's
>> implementation, but with some notable differences I'll cover here)
>>
>> The needed magic resides in the "-s" flag of the interpreter (gbx3),
>> which sets a new startup class for running the project (different from
>> the MMain/FMain class set by the user).
>>
>> We can set this flag to an hidden class exported by gb.test (for example
>> _TestRunner), which will run its Main() method directly, but in the
>> scope of the user's project. :-)
>>
>>   From there, this hidden class can do two different things (dictated by
>> CLI arguments, sent by gbtest3).
>>
>> First, walk through every class file in the hidden ".gambas" directory,
>> keep only the classes that inherit from TestModule/TestContainer (name
>> still up to bikeshedding, I prefer the first personally), then list all
>> the callable test methods. Then this list of tests is sent back to
>> gbtest3 to make the test plan before any test is run.
> 
> Please. Did you look at my code?
> 
> That does that all! Sigh ...

I'm sorry, I may have been missing something again, but you are talking 
about this code here, right ?

https://github.com/Deganius/gb.deg.unittest/tree/develop (the develop 
branch, not the master one)

If this is indeed your latest work, the public API you have implemented 
does indeed look like what I'm proposing in my previous messages (only a 
bit less concise, but still globally the same idea), but your inner 
implementation does not do many things I'm discussing here : mainly 
testing in separate, multiple processes, streaming TAP output, splitting 
gbtest3/gb.test, and Assertions that stop the execution flow.

I apologize if my previous messages look too imperative, I assure you 
this is not the intent. The goal of these is to simply discuss subjects 
that I think are important, and also to confirm things that have been 
done/discussed already so it is clear for everyone reading.

Kind regards,

-- 
Adrien Prokopowicz