[Gambas-user] Using test interface for scripter testing

Tobias Boege taboege at gmail.com
Tue Jun 23 00:25:07 CEST 2020

On Mon, 22 Jun 2020, Brian G wrote:
> Will all of the test modules be included in the production application distribution when I do a make executable or make installation package?

I have not worked on this, so I have no idea. My advice would be to try
it out: make an executable and use `gbr3 -s` to override the startup
class to probe if the interpreter could potentially find a test module
when it is instructed to use one as the startup class.

If yes, consider opening a feature request. I vaguely remember everyone
agreeing that tests should *not* be included in "production" things.

> I am including a sample app with test module for things I will need to do my testing. As you suggested I am capturing printed output, which works, but also seems to print into the test result file. 
> Is there some better way to use test to test functions which produce printed messages.

Hmm, I am not at a computer right now which has an up-to-date Gambas
version, so I cannot run the project (plus it's bed time). But I can
see that wanting to test functions which inevitably print to stdout
as a side effect can be troublesome.

I think it would be reasonable for gb.test to get a reference to the
process's original stdout and then redirecting it to /dev/null via
Output To. This way, all unintentional Print statements or external
processes inheriting stdout and printing messages would be silenced.
At the same time you have the option to use Output To or Exec To
yourself to collect output from selected functions or subprocesses
if your tests require that.

Hopefully someone else from the gb.test task force is reading this
to give an opinion.


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

More information about the User mailing list