[Gambas-user] gb.test

[Christof Thalhofer]

Am 15.01.20 um 02:11 schrieb Benoît Minisini:

> I'd prefer adding an option to the 'gbx3' interpreter that make it run 
> all the tests through a static method somewhere in 'gb.test'.

That sounds very good! That static method is Unittest.Main() in gb.test.
It can either run all testclasses at all or only one testclass or even
one testmethod in one testclass. So gbx3 should be able to be called
like this:

gbx3 -t project
gbx3 -t textclass project
gbx3 -t textclass testmethod project

Would that be possible?

> To recognize what are the test classes, is it mandatory to make them 
> inherit a specific parent class?

In the current state of the project I did not find a way around this. I
don't like it very much and i hate that the classes have to be exported.

If there was a more elegant way I would appreciate that the most!

I mainly used the inheritance to let Unittest.Main() determine the test
classes, to create objects from these and execute their testmethods (all
symbols whose names begin with "Test", "Setup", "Teardown").

But if the interpreter has its own way to determine and enumerate the
testmethods and testclasses the inheritation is not needed any more as I
think. The tests itself are done by Assert.module.

> Because we can assume that a special directory (for example 
> '.src/.test') in the project will store all the tests, and I can make 
> special support for that directory in the IDE (The '.test' directory 
> will become a special folder in the project tree).
>
> Then the compiler will be able to detect that directory, compile the 
> files inside as normal classes, but at the end make a list of all test 
> classes in a dedicated file in the project root directory ('.test' again?).
> 
> That way, the 'gb.test' component will just have to open that text file 
> to know the name of each test classes, and run what it should run in it.
>
> Another different idea would be creating a new source file extension 
> ('*.test') that would represent a module whose code is the test for the 
> real source file having the same name.
> 
> In that case, a test has to be a module, not a class, a form, or 
> anything else.

My instincts let me prefer modules very much if that would be possible.

I would also prefer *.test classes instead of a special directory as
they provide more flexibility to the developer. It lets the developer
decide if he/she wants to place a testclass inside a directory named
"Tests" (as I currently do it) or put it nearby the class to be tested
or even both.

> I really like that idea because it makes the structure of the tests 
> similar to the structure of the source code, and allows to check things 
> like: is the source code newer that the test code? But maybe it is not 
> flexible enough for special test cases, I dunno.

The latter I think. IMO there should not be a hard-coded coincidence
between a class and it's test. For instance if I have testclasses that
test the interplay between several classes I would name them
"TestClassXWithClassY".

About the quality of testing:

If one changes the source code the test code has not necessarily to be
changed also. Normally it's the other way round: First I write the test
and then the code has to fulfill what the test needs. And if later the
code is changed (maybe because of a bug) the old(!) test code assures
that things do not break by accident. So almost always the test code is
older and that's not a bad sign.

In professional software development there exists the concept of "code
coverage" to determine the quality of the testing of a project. There,
the lines of code executed by tests are counted and compared with the
lines not executed. In some projects the aim is 100 % code coverage
(needed for airplanes and pacemakers).

This can only be done by the instance performing the tests and this
would be a task we maybe could do later. But we should take care not do
things now that prevent it later.

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/20200115/40a3639d/attachment-0001.sig>