From adrien.prokopowicz at ...176...  Tue Dec  9 01:57:43 2014
From: adrien.prokopowicz at ...176... (Adrien Prokopowicz)
Date: Tue, 09 Dec 2014 01:57:43 +0100
Subject: [Gambas-devel] Suggestion : Gambas Unit Testing
Message-ID: <op.xqksyhntdlsaci@...707...>

Hello everyone !

With the amount of features to test in my various Gambas projects, I  
started feeling that it was a pain to write the tests, run *all* of them,  
and analyzing their output each time I had to make a change, thus leading  
to forget to run simple tests (see the last gb.xml issue...).

Therefore, in order to automate and simplify this whole process, I decided  
to start working on an Unit Testing component for Gambas.

It works quite simply : in your project, just create a class that inherits  
the UnitTest class, move it inside an "unit" folder in your project source  
directory, and implement your test in the _Run() method, using the  
different Assert() and Fail() methods, documented in the component's  
'AssertionsTests' test.

To run all the tests at once, just use the _UnitTestLauncher module as the  
starting class instead of your project's default one (this can be achieved  
easily using 'gbx3 -s _UnitTestLauncher' inside your project's directory.
Each test is run inside a separate Task, therefore preventing a bad test  
to crash the whole test suite, and allowing you to easily multi-task it,  
using 'gbx3 -s _UnitTestLauncher -- -j <number of parallel tasks>'.

Inside the attached component, I also made 3 tests, that show how the  
component handles the different scenarios :

- The 'MyGoodUnitTest' will run fine, but will sleep 0.5s before ending  
(to show that the component will use another thread to run the other  
tests, if there is any available, which is not the case by default).
- The 'MyBadUnitTest' will fail because of an (obvious) false assert. It  
will then show the stack trace of where the error raised, as well as a  
reason text (or just 'Assertion failed.' by default).
- The 'MyVeryBadUnitTest' will fail because of an error raised by the  
interpreter, here 'Division by zero'. Note that the result will be similar  
if the test completely crashes (Segfault...), you just won't have a stack  
trace available.

Of course this is just a proof of concept, there are a few things i would  
like to add to properly finish this component, such as a proper IDE  
integration, a standardized xUnit XML output, tweaking the archiver so the  
tests won't be in the final executable, maybe its own command (like gbt3)  
...

What do you think ?

-- 
Adrien Prokopowicz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gb.unit-0.0.1.tar.gz
Type: application/x-gzip
Size: 8133 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20141209/bdcc22ea/attachment.bin>

From jusabejusabe at ...176...  Tue Dec  9 12:35:14 2014
From: jusabejusabe at ...176... (Julio Sanchez)
Date: Tue, 9 Dec 2014 12:35:14 +0100
Subject: [Gambas-devel] Suggestion : Gambas Unit Testing
In-Reply-To: <op.xqksyhntdlsaci@...707...>
References: <op.xqksyhntdlsaci@...707...>
Message-ID: <CAFM-pnviFXbnrmHTwLQVg7L6tgzwU0WMErBYO3Q58YBDgSs3WA@...178...>

Adrien Prokopowicz:

Very interesting!!

Regards

Julio

2014-12-09 1:57 GMT+01:00 Adrien Prokopowicz <adrien.prokopowicz at ...176...>:

> Hello everyone !
>
> With the amount of features to test in my various Gambas projects, I
> started feeling that it was a pain to write the tests, run *all* of them,
> and analyzing their output each time I had to make a change, thus leading
> to forget to run simple tests (see the last gb.xml issue...).
>
> Therefore, in order to automate and simplify this whole process, I decided
> to start working on an Unit Testing component for Gambas.
>
> It works quite simply : in your project, just create a class that inherits
> the UnitTest class, move it inside an "unit" folder in your project source
> directory, and implement your test in the _Run() method, using the
> different Assert() and Fail() methods, documented in the component's
> 'AssertionsTests' test.
>
> To run all the tests at once, just use the _UnitTestLauncher module as the
> starting class instead of your project's default one (this can be achieved
> easily using 'gbx3 -s _UnitTestLauncher' inside your project's directory.
> Each test is run inside a separate Task, therefore preventing a bad test
> to crash the whole test suite, and allowing you to easily multi-task it,
> using 'gbx3 -s _UnitTestLauncher -- -j <number of parallel tasks>'.
>
> Inside the attached component, I also made 3 tests, that show how the
> component handles the different scenarios :
>
> - The 'MyGoodUnitTest' will run fine, but will sleep 0.5s before ending
> (to show that the component will use another thread to run the other tests,
> if there is any available, which is not the case by default).
> - The 'MyBadUnitTest' will fail because of an (obvious) false assert. It
> will then show the stack trace of where the error raised, as well as a
> reason text (or just 'Assertion failed.' by default).
> - The 'MyVeryBadUnitTest' will fail because of an error raised by the
> interpreter, here 'Division by zero'. Note that the result will be similar
> if the test completely crashes (Segfault...), you just won't have a stack
> trace available.
>
> Of course this is just a proof of concept, there are a few things i would
> like to add to properly finish this component, such as a proper IDE
> integration, a standardized xUnit XML output, tweaking the archiver so the
> tests won't be in the final executable, maybe its own command (like gbt3)
> ...
>
> What do you think ?
>
> --
> Adrien Prokopowicz
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20141209/2d06a432/attachment.html>

From taboege at ...176...  Tue Dec  9 16:09:23 2014
From: taboege at ...176... (Tobias Boege)
Date: Tue, 9 Dec 2014 16:09:23 +0100
Subject: [Gambas-devel] Suggestion : Gambas Unit Testing
In-Reply-To: <op.xqksyhntdlsaci@...707...>
References: <op.xqksyhntdlsaci@...707...>
Message-ID: <20141209150923.GB2486@...693...>

On Tue, 09 Dec 2014, Adrien Prokopowicz wrote:
> Hello everyone !
> 
> With the amount of features to test in my various Gambas projects, I started
> feeling that it was a pain to write the tests, run *all* of them, and
> analyzing their output each time I had to make a change, thus leading to
> forget to run simple tests (see the last gb.xml issue...).
> 
> Therefore, in order to automate and simplify this whole process, I decided
> to start working on an Unit Testing component for Gambas.
> 
> It works quite simply : in your project, just create a class that inherits
> the UnitTest class, move it inside an "unit" folder in your project source
> directory, and implement your test in the _Run() method, using the different
> Assert() and Fail() methods, documented in the component's 'AssertionsTests'
> test.
> 
> To run all the tests at once, just use the _UnitTestLauncher module as the
> starting class instead of your project's default one (this can be achieved
> easily using 'gbx3 -s _UnitTestLauncher' inside your project's directory.
> Each test is run inside a separate Task, therefore preventing a bad test to
> crash the whole test suite, and allowing you to easily multi-task it, using
> 'gbx3 -s _UnitTestLauncher -- -j <number of parallel tasks>'.
> 
> Inside the attached component, I also made 3 tests, that show how the
> component handles the different scenarios :
> 
> - The 'MyGoodUnitTest' will run fine, but will sleep 0.5s before ending (to
> show that the component will use another thread to run the other tests, if
> there is any available, which is not the case by default).
> - The 'MyBadUnitTest' will fail because of an (obvious) false assert. It
> will then show the stack trace of where the error raised, as well as a
> reason text (or just 'Assertion failed.' by default).
> - The 'MyVeryBadUnitTest' will fail because of an error raised by the
> interpreter, here 'Division by zero'. Note that the result will be similar
> if the test completely crashes (Segfault...), you just won't have a stack
> trace available.
> 
> Of course this is just a proof of concept, there are a few things i would
> like to add to properly finish this component, such as a proper IDE
> integration, a standardized xUnit XML output, tweaking the archiver so the
> tests won't be in the final executable, maybe its own command (like gbt3)
> ...
> 
> What do you think ?
> 

I know some people who waited for this. Thank you!

An extra "gbt3" would be the way I prefer, and maybe *somehow* the ability
to specify tests in plain text, i.e. not Gambas code. But that point can
safely be left for the future.

I always imagined the IDE integration to happen in a new .unit directory in
the project directory. This would also enable the archiver to leave unit
tests out when creating a *.gambas file. At least it would be nice if source
and unit tests are somehow separated.

Regards,
Tobi

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



From gambas.fr at ...176...  Tue Dec  9 17:50:47 2014
From: gambas.fr at ...176... (Fabien Bodard)
Date: Tue, 9 Dec 2014 17:50:47 +0100
Subject: [Gambas-devel] Auto binding
Message-ID: <CAFkCsL54o2pKb5MWUoxyp-j90pHtMzX9-Vte9PD3GgH=yX+mUg@...178...>

Well ... is one day we can do something like that :

http://docs.opencv.org/trunk/doc/py_tutorials/py_bindings/py_bindings_basics/py_bindings_basics.html#bindings-basics

-- 
Fabien Bodard



From adrien.prokopowicz at ...176...  Tue Dec  9 21:48:07 2014
From: adrien.prokopowicz at ...176... (Adrien Prokopowicz)
Date: Tue, 09 Dec 2014 21:48:07 +0100
Subject: [Gambas-devel] Suggestion : Gambas Unit Testing
In-Reply-To: <20141209150923.GB2486@...693...>
References: <op.xqksyhntdlsaci@...707...> <20141209150923.GB2486@...693...>
Message-ID: <op.xqmb2hbsdlsaci@...707...>

Le Tue, 09 Dec 2014 16:09:23 +0100, Tobias Boege <taboege at ...176...> wrote:

> On Tue, 09 Dec 2014, Adrien Prokopowicz wrote:
>> [...]
>
> I know some people who waited for this. Thank you!
>
> An extra "gbt3" would be the way I prefer, and maybe *somehow* the  
> ability
> to specify tests in plain text, i.e. not Gambas code. But that point can
> safely be left for the future.
>

I would still like to know precisely what you have in mind, though. :)

> I always imagined the IDE integration to happen in a new .unit directory  
> in the project directory. This would also enable the archiver to leave 
> unit tests out when creating a *.gambas file. At least it would be nice  
> if source and unit tests are somehow separated.
>
> Regards,
> Tobi
>

At first, I wanted to put the unit test in the .src/.unit directory. It  
was compiling and running fine, but the directory (and its files) didn't  
show up in the IDE. So until the IDE supports it, tests will stay in  
.src/unit.

I like the idea of putting them in a new .unit directory next to .src, but  
this may require quite a bit of changes in the compiler. I guess Beno?t  
will tell us if it is (reasonably) possible.

-- 
Adrien Prokopowicz



From taboege at ...176...  Tue Dec  9 22:20:13 2014
From: taboege at ...176... (Tobias Boege)
Date: Tue, 9 Dec 2014 22:20:13 +0100
Subject: [Gambas-devel] Suggestion : Gambas Unit Testing
In-Reply-To: <op.xqmb2hbsdlsaci@...707...>
References: <op.xqksyhntdlsaci@...707...> <20141209150923.GB2486@...693...>
	<op.xqmb2hbsdlsaci@...707...>
Message-ID: <20141209212013.GH2486@...693...>

On Tue, 09 Dec 2014, Adrien Prokopowicz wrote:
> Le Tue, 09 Dec 2014 16:09:23 +0100, Tobias Boege <taboege at ...176...> wrote:
> 
> > On Tue, 09 Dec 2014, Adrien Prokopowicz wrote:
> >> [...]
> >
> > I know some people who waited for this. Thank you!
> >
> > An extra "gbt3" would be the way I prefer, and maybe *somehow* the  
> > ability
> > to specify tests in plain text, i.e. not Gambas code. But that point can
> > safely be left for the future.
> >
> 
> I would still like to know precisely what you have in mind, though. :)
> 

Suppose your class LagrangeInterp.class can interpolate polynomials from
given data sets using Lagrange's method. Its interface is

  Public Sub _call(X As Float[], Y As Float[]) As Polynomial

I would like to be able to write into a text file, say lagrange.unit,

  ...
  LagrangeInterp([1,2,3], [1,4,9]) = "x^2"
  LagrangeInterp([], []) Error
  ...

and then call

  $ gbt3 /path/to/my/project <lagrange.unit

to unit-test my project -- imagine that we want to do that from a cronjob,
after a new Gambas version was built.

Note that LagrangeInterp([1,2,3], [1,4,9]) and LagrangeInterp([], []) is
valid Gambas code which can be Eval()'d in a suitable environment. The first
line asserts that the Polynomial object returned from that call has a string
representation "x^2". Polynomials can safely be CStr()'d. That's what makes
it reasonable to discuss this level of comfort. The second call should raise
an error which is indicated by the "Error" keyword instead of some equality
assertion.

As I said, this is only about comfort -- comfort that can later be
implemented on top of the working unit tester and a level of comfort that is
still *feasible*. E.g. the first line would be converted by a parser into a
sequence like this:

  Dim sLine As String
  Dim vExpected, vResult As Variant

  ' Sample data
  sLine = "LagrangeInterp([1,2,3], [1,4,9]) = \"x^2\""

  ' For equality assertions:
  With Scan(sLine, "* = *")
    vResult = Eval(.[0])  ' Requires that the LagrangeInterp class is loaded![*]
    vExpect = Eval(.[1])
    If TypeOf(vExpect) = gb.String Then  ' [+]
      If CStr(vResult) = vExpect Then Print "OK"
    Endif
  End With

[*] Maybe we can list all the used classes in the header of such a file and
    load them explicitely using Class.Load()? I don't know if that would
    work.

[+] I don't know off the top of my head if this If statement is necessary.
    Maybe the code

      If vResult = vExpect Then Print "OK"

    would suffice as it may trigger an automatic conversion of vResult to
    vExpect's type which is String in this example.

Just an idea.

Regards,
Tobi

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



From gambas at ...1...  Tue Dec  9 22:45:01 2014
From: gambas at ...1... (=?windows-1252?Q?Beno=EEt_Minisini?=)
Date: Tue, 09 Dec 2014 22:45:01 +0100
Subject: [Gambas-devel] Suggestion : Gambas Unit Testing
In-Reply-To: <20141209212013.GH2486@...693...>
References: <op.xqksyhntdlsaci@...707...>
	<20141209150923.GB2486@...693...>	<op.xqmb2hbsdlsaci@...707...>
	<20141209212013.GH2486@...693...>
Message-ID: <54876D5D.1040707@...1...>

I like the Tobias' idea of "just" comparing the result of a unit test 
with a text file, like in Python. I wrote "just" because there must be 
some pattern matching magic in the comparison.

But I prefer the Adrian way of coding all the tests inside the project.

I can add a new special hidden directory for storing the "UnitTests". It 
will be compiled like the rest of the code, and will be put inside the 
executable. It will be run by a special option of gbx3 / gbr3.

For example, if you have a "gb.abcd" component, you will run something like:

$ gbr3 -t gb.abcd.gambas

to execute the unit tests and check the result.

Moreover, we can make "UnitTest" a new "form" type in the IDE. We could 
store the code to test in the class, that class automatically inheriting 
the UnitTest class. And the form file would be just the textual result 
that must be emitted by the tests.

What do you think about that?

-- 
Beno?t Minisini



From jusabejusabe at ...176...  Tue Dec  9 23:50:59 2014
From: jusabejusabe at ...176... (Julio Sanchez)
Date: Tue, 9 Dec 2014 23:50:59 +0100
Subject: [Gambas-devel] Suggestion : Gambas Unit Testing
In-Reply-To: <54876D5D.1040707@...1...>
References: <op.xqksyhntdlsaci@...707...> <20141209150923.GB2486@...693...>
	<op.xqmb2hbsdlsaci@...707...> <20141209212013.GH2486@...693...>
	<54876D5D.1040707@...1...>
Message-ID: <CAFM-pns29tVD6GkDCnbUXXDjsa5fAacho3g172oEfUH3JqGjWA@...178...>

I think that should be integrated into the IDE, but  not a new form of the
project (what happens with projects that either alone console mode?).

In the IDE, you should have a new option to "run unit tests" and display a
form or tab with  the results of the test, as does eclipse, for example.

https://drive.google.com/file/d/0B02Ro2CNt-OOdGFNMHEtNHFpWU0/view?usp=sharing

All unit tests, the programmer would place in a project folder for example
.scr/unit

It's an idea ... what you think?

Regards
Julio

2014-12-09 22:45 GMT+01:00 Beno?t Minisini <gambas at ...1...>:

> I like the Tobias' idea of "just" comparing the result of a unit test
> with a text file, like in Python. I wrote "just" because there must be
> some pattern matching magic in the comparison.
>
> But I prefer the Adrian way of coding all the tests inside the project.
>
> I can add a new special hidden directory for storing the "UnitTests". It
> will be compiled like the rest of the code, and will be put inside the
> executable. It will be run by a special option of gbx3 / gbr3.
>
> For example, if you have a "gb.abcd" component, you will run something
> like:
>
> $ gbr3 -t gb.abcd.gambas
>
> to execute the unit tests and check the result.
>
> Moreover, we can make "UnitTest" a new "form" type in the IDE. We could
> store the code to test in the class, that class automatically inheriting
> the UnitTest class. And the form file would be just the textual result
> that must be emitted by the tests.
>
> What do you think about that?
>
> --
> Beno?t Minisini
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20141209/25d298f6/attachment.html>

From gambas at ...1...  Tue Dec  9 23:59:59 2014
From: gambas at ...1... (=?windows-1252?Q?Beno=EEt_Minisini?=)
Date: Tue, 09 Dec 2014 23:59:59 +0100
Subject: [Gambas-devel] Suggestion : Gambas Unit Testing
In-Reply-To: <CAFM-pns29tVD6GkDCnbUXXDjsa5fAacho3g172oEfUH3JqGjWA@...178...>
References: <op.xqksyhntdlsaci@...707...>
	<20141209150923.GB2486@...693...>	<op.xqmb2hbsdlsaci@...707...>
	<20141209212013.GH2486@...693...>	<54876D5D.1040707@...1...>
	<CAFM-pns29tVD6GkDCnbUXXDjsa5fAacho3g172oEfUH3JqGjWA@...178...>
Message-ID: <54877EEF.1070101@...1...>

Le 09/12/2014 23:50, Julio Sanchez a ?crit :
> I think that should be integrated into the IDE, but  not a new form of
> the project (what happens with projects that either alone console mode?).

An IDE form is not necessarily a GUI form!

An IDE form is:

- Associated with a component that "implements" it.

- A class that automatically inherits another class whose name if the 
form type. That "form" class is located in the above component.

- A bunch of code that implements it in the IDE.

>
> In the IDE, you should have a new option to "run unit tests" and display
> a form or tab with  the results of the test, as does eclipse, for example.
>
> https://drive.google.com/file/d/0B02Ro2CNt-OOdGFNMHEtNHFpWU0/view?usp=sharing

Eventually.

>
> All unit tests, the programmer would place in a project folder for
> example .scr/unit
>
> It's an idea ... what you think?

Unit test classes will go to their own directory in the project tree 
view. Where they are exactly located on the disk is hidden by the IDE.

Regards,

-- 
Beno?t Minisini



From jusabejusabe at ...176...  Wed Dec 10 00:11:13 2014
From: jusabejusabe at ...176... (Julio Sanchez)
Date: Wed, 10 Dec 2014 00:11:13 +0100
Subject: [Gambas-devel] Suggestion : Gambas Unit Testing
In-Reply-To: <54877EEF.1070101@...1...>
References: <op.xqksyhntdlsaci@...707...> <20141209150923.GB2486@...693...>
	<op.xqmb2hbsdlsaci@...707...> <20141209212013.GH2486@...693...>
	<54876D5D.1040707@...1...>
	<CAFM-pns29tVD6GkDCnbUXXDjsa5fAacho3g172oEfUH3JqGjWA@...178...>
	<54877EEF.1070101@...1...>
Message-ID: <CAFM-pntGH+XO_x=kDsLYrGn=vLMs_z_k2SdVbbd49-NPfwLLMQ@...178...>

>An IDE form is not necessarily a GUI form!...

Ok, I had misunderstood

Regards,


2014-12-09 23:59 GMT+01:00 Beno?t Minisini <gambas at ...1...>:

> Le 09/12/2014 23:50, Julio Sanchez a ?crit :
> > I think that should be integrated into the IDE, but  not a new form of
> > the project (what happens with projects that either alone console mode?).
>
> An IDE form is not necessarily a GUI form!
>
> An IDE form is:
>
> - Associated with a component that "implements" it.
>
> - A class that automatically inherits another class whose name if the
> form type. That "form" class is located in the above component.
>
> - A bunch of code that implements it in the IDE.
>
> >
> > In the IDE, you should have a new option to "run unit tests" and display
> > a form or tab with  the results of the test, as does eclipse, for
> example.
> >
> >
> https://drive.google.com/file/d/0B02Ro2CNt-OOdGFNMHEtNHFpWU0/view?usp=sharing
>
> Eventually.
>
> >
> > All unit tests, the programmer would place in a project folder for
> > example .scr/unit
> >
> > It's an idea ... what you think?
>
> Unit test classes will go to their own directory in the project tree
> view. Where they are exactly located on the disk is hidden by the IDE.
>
> Regards,
>
> --
> Beno?t Minisini
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20141210/1a1ee128/attachment.html>

From adrien.prokopowicz at ...176...  Wed Dec 10 04:08:41 2014
From: adrien.prokopowicz at ...176... (Adrien Prokopowicz)
Date: Wed, 10 Dec 2014 04:08:41 +0100
Subject: [Gambas-devel] Suggestion : Gambas Unit Testing
In-Reply-To: <54876D5D.1040707@...1...>
References: <op.xqksyhntdlsaci@...707...> <20141209150923.GB2486@...693...>
	<op.xqmb2hbsdlsaci@...707...> <20141209212013.GH2486@...693...>
	<54876D5D.1040707@...1...>
Message-ID: <op.xqmtoroldlsaci@...707...>

Le Tue, 09 Dec 2014 22:45:01 +0100, Beno?t Minisini
<gambas at ...1...> a ?crit:

> I like the Tobias' idea of "just" comparing the result of a unit test
> with a text file, like in Python. I wrote "just" because there must be
> some pattern matching magic in the comparison.
>
> But I prefer the Adrian way of coding all the tests inside the project.

I like Tobias' idea too, it can be handy to write fast little tests, even
if it is quite limited compared to writing actual code.

> I can add a new special hidden directory for storing the "UnitTests". It
> will be compiled like the rest of the code, and will be put inside the
> executable. It will be run by a special option of gbx3 / gbr3.
>
> For example, if you have a "gb.abcd" component, you will run something  
> like:
>
> $ gbr3 -t gb.abcd.gambas
>
> to execute the unit tests and check the result.

I do not like the idea of having the unit tests in the final executable.
To me, unit testing should be used for development purposes only, not
something the end user should see.

Plus, if a project has a lot of unit tests (100+ is a reasonable number),
and optionally a good amount of test data (in the case of gb.xml, for
example, I would put a few hundreds of XML/HTML files to test the parser),
it would end up wasting a noticeable amount of the user's disk space.

> Moreover, we can make "UnitTest" a new "form" type in the IDE. We could
> store the code to test in the class, that class automatically inheriting
> the UnitTest class. And the form file would be just the textual result
> that must be emitted by the tests.
>
> What do you think about that?

A test's result should not rely on its standard output IMHO. There are
too many ways this could go wrong for the test writer (an extra space
here, a little typo there...). Additionally, it would not be very
indicative about why/where the test failed (no stack trace or error
message), and I think that maintaining two files for a test would quickly
become a pain. Relying only on the Assert() methods is the best solution
to me.

For IDE integration, what I had in mind was, as you said, creating a
new "form" type, so you could simply do New>Unit Test..., give it a name
and immediately start implementing the pre-generated _Run() method.
Then, starting a test (either automatically after compilation or manually
 from a menu entry) would open a tab containing the full report.
I can work on that if you want.

In the meantime, I will start working on a class to manage and retrieve
the results from the testing process, so it can directly be used by the
IDE (and maybe other projects).

-- 
Adrien Prokopowicz



From gambas at ...1...  Wed Dec 10 08:20:24 2014
From: gambas at ...1... (=?UTF-8?B?QmVub8OudCBNaW5pc2luaQ==?=)
Date: Wed, 10 Dec 2014 08:20:24 +0100
Subject: [Gambas-devel] Suggestion : Gambas Unit Testing
In-Reply-To: <op.xqmtoroldlsaci@...707...>
References: <op.xqksyhntdlsaci@...707...>
	<20141209150923.GB2486@...693...>	<op.xqmb2hbsdlsaci@...707...>
	<20141209212013.GH2486@...693...>	<54876D5D.1040707@...1...>
	<op.xqmtoroldlsaci@...707...>
Message-ID: <5487F438.9000504@...1...>

Le 10/12/2014 04:08, Adrien Prokopowicz a ?crit :
> Le Tue, 09 Dec 2014 22:45:01 +0100, Beno?t Minisini
> <gambas at ...1...> a ?crit:
>
>> I like the Tobias' idea of "just" comparing the result of a unit test
>> with a text file, like in Python. I wrote "just" because there must be
>> some pattern matching magic in the comparison.
>>
>> But I prefer the Adrian way of coding all the tests inside the project.
>
> I like Tobias' idea too, it can be handy to write fast little tests, even
> if it is quite limited compared to writing actual code.
>
>> I can add a new special hidden directory for storing the "UnitTests". It
>> will be compiled like the rest of the code, and will be put inside the
>> executable. It will be run by a special option of gbx3 / gbr3.
>>
>> For example, if you have a "gb.abcd" component, you will run something
>> like:
>>
>> $ gbr3 -t gb.abcd.gambas
>>
>> to execute the unit tests and check the result.
>
> I do not like the idea of having the unit tests in the final executable.
> To me, unit testing should be used for development purposes only, not
> something the end user should see.
>
> Plus, if a project has a lot of unit tests (100+ is a reasonable number),
> and optionally a good amount of test data (in the case of gb.xml, for
> example, I would put a few hundreds of XML/HTML files to test the parser),
> it would end up wasting a noticeable amount of the user's disk space.

As unit test classes will be stored in their own directories, it should 
be easy for the archiver not to include them.

>
>> Moreover, we can make "UnitTest" a new "form" type in the IDE. We could
>> store the code to test in the class, that class automatically inheriting
>> the UnitTest class. And the form file would be just the textual result
>> that must be emitted by the tests.
>>
>> What do you think about that?
>
> A test's result should not rely on its standard output IMHO. There are
> too many ways this could go wrong for the test writer (an extra space
> here, a little typo there...).

This is why there will be pattern matching magic. i.e. some part of the 
expected outputs will be 'jokers'.

> Additionally, it would not be very
> indicative about why/where the test failed (no stack trace or error
> message), and I think that maintaining two files for a test would quickly
> become a pain. Relying only on the Assert() methods is the best solution
> to me.
>

This is a better argument. I can't tell what is the best, as I never use 
these kinds of things a lot.

> For IDE integration, what I had in mind was, as you said, creating a
> new "form" type, so you could simply do New>Unit Test..., give it a name
> and immediately start implementing the pre-generated _Run() method.

Why an hidden method?

> Then, starting a test (either automatically after compilation or manually
>   from a menu entry) would open a tab containing the full report.
> I can work on that if you want.
>
> In the meantime, I will start working on a class to manage and retrieve
> the results from the testing process, so it can directly be used by the
> IDE (and maybe other projects).
>

OK, so the tests results should be a text file format easily transformed 
into a nice table by the IDE. Please don't use XML. :-)

Regards,

-- 
Beno?t Minisini



From adrien.prokopowicz at ...176...  Wed Dec 10 10:35:38 2014
From: adrien.prokopowicz at ...176... (Adrien Prokopowicz)
Date: Wed, 10 Dec 2014 10:35:38 +0100
Subject: [Gambas-devel] Suggestion : Gambas Unit Testing
In-Reply-To: <5487F438.9000504@...1...>
References: <op.xqksyhntdlsaci@...707...> <20141209150923.GB2486@...693...>
	<op.xqmb2hbsdlsaci@...707...> <20141209212013.GH2486@...693...>
	<54876D5D.1040707@...1...>
	<op.xqmtoroldlsaci@...707...>
	<5487F438.9000504@...1...>
Message-ID: <op.xqnbloeudlsaci@...707...>

Le Wed, 10 Dec 2014 08:20:24 +0100, Beno?t Minisini  
<gambas at ...1...> a ?crit:

> Le 10/12/2014 04:08, Adrien Prokopowicz a ?crit :
>> Le Tue, 09 Dec 2014 22:45:01 +0100, Beno?t Minisini
>> <gambas at ...1...> a ?crit:
>>>
>>> [...]
>>>
>>> Moreover, we can make "UnitTest" a new "form" type in the IDE. We could
>>> store the code to test in the class, that class automatically  
>>> inheriting
>>> the UnitTest class. And the form file would be just the textual result
>>> that must be emitted by the tests.
>>>
>>> What do you think about that?
>>
>> A test's result should not rely on its standard output IMHO. There are
>> too many ways this could go wrong for the test writer (an extra space
>> here, a little typo there...).
>
> This is why there will be pattern matching magic. i.e. some part of the
> expected outputs will be 'jokers'.
>

Oh, I didn't catch the "pattern matching magic" part here. I thought it
was only for Tobias' idea, my bad.
Although this doesn't change much my point of view (see below).

>> Additionally, it would not be very
>> indicative about why/where the test failed (no stack trace or error
>> message), and I think that maintaining two files for a test would  
>> quickly
>> become a pain. Relying only on the Assert() methods is the best solution
>> to me.
>>
>
> This is a better argument. I can't tell what is the best, as I never use
> these kinds of things a lot.
>

I see a 'basic test case' like this :

	'If we use standard output comparison
	myObject = giveMeMyObject()
	Print myObject.value1
	Print myObject.value2	
	-- MyOtherFile.txt -- 8< --
	"expected value 1"
	"expected value 2"

      -- vs. --

	'If we use the assets() methods
	myObject = giveMeMyObject()
	Me.Assert(myObject.value1 = "expected value 1")
	Me.Assert(myObject.value2 = "expected value 2")

I don't know about you, but to me the second option looks way clearer and
easier to maintain. :-)

>> For IDE integration, what I had in mind was, as you said, creating a
>> new "form" type, so you could simply do New>Unit Test..., give it a name
>> and immediately start implementing the pre-generated _Run() method.
>
> Why an hidden method?
>

Because calling this method would run the test, but not update the
UnitTest's internal state variables, nor catch the (potential) errors
correctly. You should use the public Start() method for that.

Another (cleaner) possibility would be switching this method's
accessibility to protected (bumping Tobias' thread here [0]). ;)

>> Then, starting a test (either automatically after compilation or  
>> manually
>>   from a menu entry) would open a tab containing the full report.
>> I can work on that if you want.
>>
>> In the meantime, I will start working on a class to manage and retrieve
>> the results from the testing process, so it can directly be used by the
>> IDE (and maybe other projects).
>>
>
> OK, so the tests results should be a text file format easily transformed
> into a nice table by the IDE. Please don't use XML. :-)

I thought about using a text file only for importing/exporting test  
results,
because I would like the IDE's report to be updated in (almost) real-time.
For example, if only 30 of the 100 tests are done, it would be nice to show
them already, rather than just having a waiting cursor.

But don't worry, neither of the two will be implemented using XML. :-)
The only thing I'm wondering about the file format if it should be
human-readable or not...

-- 
Adrien Prokopowicz

[0] http://sourceforge.net/p/gambas/mailman/message/32993566/



From gambas at ...1...  Wed Dec 10 10:52:22 2014
From: gambas at ...1... (=?UTF-8?B?QmVub8OudCBNaW5pc2luaQ==?=)
Date: Wed, 10 Dec 2014 10:52:22 +0100
Subject: [Gambas-devel] Suggestion : Gambas Unit Testing
In-Reply-To: <op.xqnbloeudlsaci@...707...>
References: <op.xqksyhntdlsaci@...707...>
	<20141209150923.GB2486@...693...>	<op.xqmb2hbsdlsaci@...707...>
	<20141209212013.GH2486@...693...>	<54876D5D.1040707@...1...>	<op.xqmtoroldlsaci@...707...>	<5487F438.9000504@...1...>
	<op.xqnbloeudlsaci@...707...>
Message-ID: <548817D6.3060301@...1...>

Le 10/12/2014 10:35, Adrien Prokopowicz a ?crit :
>
> I see a 'basic test case' like this :
>
> 	'If we use standard output comparison
> 	myObject = giveMeMyObject()
> 	Print myObject.value1
> 	Print myObject.value2	
> 	-- MyOtherFile.txt -- 8< --
> 	"expected value 1"
> 	"expected value 2"
>
>        -- vs. --
>
> 	'If we use the assets() methods
> 	myObject = giveMeMyObject()
> 	Me.Assert(myObject.value1 = "expected value 1")
> 	Me.Assert(myObject.value2 = "expected value 2")
>
> I don't know about you, but to me the second option looks way clearer and
> easier to maintain. :-)
>
>>> For IDE integration, what I had in mind was, as you said, creating a
>>> new "form" type, so you could simply do New>Unit Test..., give it a name
>>> and immediately start implementing the pre-generated _Run() method.
>>
>> Why an hidden method?
>>
>
> Because calling this method would run the test, but not update the
> UnitTest's internal state variables, nor catch the (potential) errors
> correctly. You should use the public Start() method for that.

It's not a valid argument for me. If the user has to write the method, 
it must have a normal public name.

Moreover, running the UnitTest will start the static public Main() 
method, so the Start() method should be named Main(), or called by Main().

>
> Another (cleaner) possibility would be switching this method's
> accessibility to protected (bumping Tobias' thread here [0]). ;)
>
>>> Then, starting a test (either automatically after compilation or
>>> manually
>>>    from a menu entry) would open a tab containing the full report.
>>> I can work on that if you want.
>>>
>>> In the meantime, I will start working on a class to manage and retrieve
>>> the results from the testing process, so it can directly be used by the
>>> IDE (and maybe other projects).
>>>
>>
>> OK, so the tests results should be a text file format easily transformed
>> into a nice table by the IDE. Please don't use XML. :-)
>
> I thought about using a text file only for importing/exporting test
> results,
> because I would like the IDE's report to be updated in (almost) real-time.
> For example, if only 30 of the 100 tests are done, it would be nice to show
> them already, rather than just having a waiting cursor.

Nice, but what for? If you run a test, you won't modify the project at 
the same time...

But the unittest must be runnable from the command line, so its output 
should be text printed on the standard output. So we can imagine that 
they are run in the background by the IDE, and that the output will be 
catched and transformed in a nice result table. And then you gain your 
"real-time" feature.

Regards,

-- 
Beno?t Minisini



From adrien.prokopowicz at ...176...  Wed Dec 10 23:20:29 2014
From: adrien.prokopowicz at ...176... (Adrien Prokopowicz)
Date: Wed, 10 Dec 2014 23:20:29 +0100
Subject: [Gambas-devel] Suggestion : Gambas Unit Testing
In-Reply-To: <548817D6.3060301@...1...>
References: <op.xqksyhntdlsaci@...707...> <20141209150923.GB2486@...693...>
	<op.xqmb2hbsdlsaci@...707...> <20141209212013.GH2486@...693...>
	<54876D5D.1040707@...1...>
	<op.xqmtoroldlsaci@...707...>
	<5487F438.9000504@...1...>
	<op.xqnbloeudlsaci@...707...>
	<548817D6.3060301@...1...>
Message-ID: <op.xqoa0fnodlsaci@...707...>

Le Wed, 10 Dec 2014 10:52:22 +0100, Beno?t Minisini  
<gambas at ...1...> a ?crit:

> Le 10/12/2014 10:35, Adrien Prokopowicz a ?crit :
>
>> Because calling this method would run the test, but not update the
>> UnitTest's internal state variables, nor catch the (potential) errors
>> correctly. You should use the public Start() method for that.
>
> It's not a valid argument for me. If the user has to write the method,
> it must have a normal public name.

I agree. That's why I was suggesting the protected accessibility.

> Moreover, running the UnitTest will start the static public Main()
> method, so the Start() method should be named Main(), or called by  
> Main().

I don't understand, what 'static public Main()' are you talking about ?
There is no such method in UnitTest : the test is never ran directly,
it's the _UnitTestLauncher that creates a task for each UnitTest, which
then runs the test.

Actually, the Start() method should not even be exported, as the user
never starts a test from application code (only the launcher does that).

I will have to change the UnitTest class quite a bit, so that internal
methods stay away from user-accessible methods (like Start).

>> I thought about using a text file only for importing/exporting test
>> results,
>> because I would like the IDE's report to be updated in (almost)  
>> real-time.
>> For example, if only 30 of the 100 tests are done, it would be nice to  
>> show
>> them already, rather than just having a waiting cursor.
>
> Nice, but what for? If you run a test, you won't modify the project at
> the same time...

Just for user comfort. Personally, I find it very frustrating when an
application just tells you "please wait" when you could already see part
of the results. But maybe it's just me.

> But the unittest must be runnable from the command line, so its output
> should be text printed on the standard output. So we can imagine that
> they are run in the background by the IDE, and that the output will be
> catched and transformed in a nice result table. And then you gain your
> "real-time" feature.

Unit tests are already runnable from command line (the command is just
ugly at the moment), the following works on any project for which
the gb.unit component is enabled :

   [adrien at ...707... gb.unit]$ gbx3 ./ -s "_UnitTestLauncher"
   ----- Test AssertionsTests (#0) succeeded -----
   ----- Test MyBadUnitTest (#1) failed -----
	  Reason: Assertion failed.
	  Stack trace :
		  MyBadUnitTest._Run.8
   ----- Test MyGoodUnitTest (#2) succeeded -----
   ----- Test MyVeryBadUnitTest (#3) failed -----
	  MyVeryBadUnitTest failed due to an unexpected error.
	  Reason: Division by zero
	  Stack trace :
		  MyVeryBadUnitTest._Run.8
   4 tests finished. 2 sucessful tests, 2 failed tests.
   [adrien at ...707... gb.unit]$

I plan to add another flag to this command that would transform the
output into something more convenient to parse for the IDE.

Regards,

-- 
Adrien Prokopowicz



From sebikul at ...176...  Fri Dec 12 01:58:50 2014
From: sebikul at ...176... (Sebastian Kulesz)
Date: Thu, 11 Dec 2014 21:58:50 -0300
Subject: [Gambas-devel] Installation of examples
Message-ID: <CAAkQKUZMu2Q+qaJs65O7N+7qTrLs3S3URGA5BGOSUbdqeNyxLw@...178...>

Hi! I was wondering if I should remove the gambas3-examples package or
leave it as it is. I know the directory changed but as long as the
installation path is the same it should not break anything.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20141211/730d8e73/attachment.html>

From gambas at ...1...  Fri Dec 12 10:54:11 2014
From: gambas at ...1... (=?windows-1252?Q?Beno=EEt_Minisini?=)
Date: Fri, 12 Dec 2014 10:54:11 +0100
Subject: [Gambas-devel] Installation of examples
In-Reply-To: <CAAkQKUZMu2Q+qaJs65O7N+7qTrLs3S3URGA5BGOSUbdqeNyxLw@...178...>
References: <CAAkQKUZMu2Q+qaJs65O7N+7qTrLs3S3URGA5BGOSUbdqeNyxLw@...178...>
Message-ID: <548ABB43.4080308@...1...>

Le 12/12/2014 01:58, Sebastian Kulesz a ?crit :
> Hi! I was wondering if I should remove the gambas3-examples package or
> leave it as it is. I know the directory changed but as long as the
> installation path is the same it should not break anything.
>
> Thanks!
>

Yes. The examples will be stored in the gambas farm server, so there 
won't be distributed anymore through the packages.

-- 
Beno?t Minisini



From Karl.Reinl at ...646...  Fri Dec 12 13:29:55 2014
From: Karl.Reinl at ...646... (Charlie Reinl)
Date: Fri, 12 Dec 2014 13:29:55 +0100
Subject: [Gambas-devel] Installation of examples
In-Reply-To: <548ABB43.4080308@...1...>
References: <CAAkQKUZMu2Q+qaJs65O7N+7qTrLs3S3URGA5BGOSUbdqeNyxLw@...178...>
	<548ABB43.4080308@...1...>
Message-ID: <1418387395.3554.6.camel@...102...>

Am Freitag, den 12.12.2014, 10:54 +0100 schrieb Beno?t Minisini:
> Le 12/12/2014 01:58, Sebastian Kulesz a ?crit :
> > Hi! I was wondering if I should remove the gambas3-examples package or
> > leave it as it is. I know the directory changed but as long as the
> > installation path is the same it should not break anything.
> >
> > Thanks!
> >
> 
> Yes. The examples will be stored in the gambas farm server, so there 
> won't be distributed anymore through the packages.
> 

Salut Beno?t,

I think these are bad news for all, having not a fast or stable
Internet.
So I think it should be possible to download all examples in one package
from the gambas website too. 

-- 
Amicalement
Charlie




From jusabejusabe at ...176...  Wed Dec 24 15:19:32 2014
From: jusabejusabe at ...176... (Julio Sanchez)
Date: Wed, 24 Dec 2014 15:19:32 +0100
Subject: [Gambas-devel] Suggestion : Gambas Unit Testing
In-Reply-To: <op.xqoa0fnodlsaci@...707...>
References: <op.xqksyhntdlsaci@...707...> <20141209150923.GB2486@...693...>
	<op.xqmb2hbsdlsaci@...707...> <20141209212013.GH2486@...693...>
	<54876D5D.1040707@...1...>
	<op.xqmtoroldlsaci@...707...>
	<5487F438.9000504@...1...>
	<op.xqnbloeudlsaci@...707...>
	<548817D6.3060301@...1...>
	<op.xqoa0fnodlsaci@...707...>
Message-ID: <CAFM-pnunCgmqMyxY9fJzSM18Bh+cCnyoh1d=L_KcWv8_0MvuRg@...178...>

Hi, I have added the code Adrien, a  form to display the results of the test
and  I created 3  component  (according gb.qt4 is used, gb.gtk or gb.gui),
to install in Ide gambas3

Here you have the article and a video of how to use (in Spanish):

http://jsbsan.blogspot.com.es/2014/12/pruebas-unitarias-en-gambas3-gambas.html


Merry Christmas!!!

Regards

Julio

2014-12-10 23:20 GMT+01:00 Adrien Prokopowicz <adrien.prokopowicz at ...176...>
:

> Le Wed, 10 Dec 2014 10:52:22 +0100, Beno?t Minisini
> <gambas at ...1...> a ?crit:
>
> > Le 10/12/2014 10:35, Adrien Prokopowicz a ?crit :
> >
> >> Because calling this method would run the test, but not update the
> >> UnitTest's internal state variables, nor catch the (potential) errors
> >> correctly. You should use the public Start() method for that.
> >
> > It's not a valid argument for me. If the user has to write the method,
> > it must have a normal public name.
>
> I agree. That's why I was suggesting the protected accessibility.
>
> > Moreover, running the UnitTest will start the static public Main()
> > method, so the Start() method should be named Main(), or called by
> > Main().
>
> I don't understand, what 'static public Main()' are you talking about ?
> There is no such method in UnitTest : the test is never ran directly,
> it's the _UnitTestLauncher that creates a task for each UnitTest, which
> then runs the test.
>
> Actually, the Start() method should not even be exported, as the user
> never starts a test from application code (only the launcher does that).
>
> I will have to change the UnitTest class quite a bit, so that internal
> methods stay away from user-accessible methods (like Start).
>
> >> I thought about using a text file only for importing/exporting test
> >> results,
> >> because I would like the IDE's report to be updated in (almost)
> >> real-time.
> >> For example, if only 30 of the 100 tests are done, it would be nice to
> >> show
> >> them already, rather than just having a waiting cursor.
> >
> > Nice, but what for? If you run a test, you won't modify the project at
> > the same time...
>
> Just for user comfort. Personally, I find it very frustrating when an
> application just tells you "please wait" when you could already see part
> of the results. But maybe it's just me.
>
> > But the unittest must be runnable from the command line, so its output
> > should be text printed on the standard output. So we can imagine that
> > they are run in the background by the IDE, and that the output will be
> > catched and transformed in a nice result table. And then you gain your
> > "real-time" feature.
>
> Unit tests are already runnable from command line (the command is just
> ugly at the moment), the following works on any project for which
> the gb.unit component is enabled :
>
>    [adrien at ...707... gb.unit]$ gbx3 ./ -s "_UnitTestLauncher"
>    ----- Test AssertionsTests (#0) succeeded -----
>    ----- Test MyBadUnitTest (#1) failed -----
>           Reason: Assertion failed.
>           Stack trace :
>                   MyBadUnitTest._Run.8
>    ----- Test MyGoodUnitTest (#2) succeeded -----
>    ----- Test MyVeryBadUnitTest (#3) failed -----
>           MyVeryBadUnitTest failed due to an unexpected error.
>           Reason: Division by zero
>           Stack trace :
>                   MyVeryBadUnitTest._Run.8
>    4 tests finished. 2 sucessful tests, 2 failed tests.
>    [adrien at ...707... gb.unit]$
>
> I plan to add another flag to this command that would transform the
> output into something more convenient to parse for the IDE.
>
> Regards,
>
> --
> Adrien Prokopowicz
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20141224/c1cbbc56/attachment.html>