About Testing

[Udo Spallek]

Hi,

Tryton has two general testing targets unittest (direct Tryton API
access) and scenario tests (based on proteus).
While unittests are very powerfull to intensive test small parts of
code, are scenario tests excellent for testing large functional
related parts.

Running tests with run-tests.py follows the rule first run all unittests
of a module, second run the doctests[1].

Is there a way to run a specific unittest after a specific scenario test
using both the same database? (I know about setUp and tearDown…)

I am asking, because I need to (unit-) test a reports ``objects`` and
``data`` delivered to the ``parse`` method. I can never introspect
methods in a proteus scenario test. On the other hand using a
unittest to create functional data like company, chart of account,
fiscal year, invoices, accounting moves is a lot of monkey work.
So it would be handy to have the scenario test roll out all the
functional data and after this a unittest could use the database to
introspect methods and check the calculations for the report.

Any ideas appreciated?

Regards Udo
[1]
http://hg.tryton.org/trytond/file/05645ed58599/trytond/tests/test_tryton.py#l345
--
_____________________________
virtual things
Preisler & Spallek GbR
München - Aachen

Windeckstr. 77
81375 München
Tel: +49 (89) 710 481 55
Fax: +49 (89) 710 481 56

in...@virtual-things.biz
http://www.virtual-things.biz

[Cédric Krier]

On 2016-01-29 18:40, 'Udo Spallek' via tryton-dev wrote:
> Hi,
>
> Tryton has two general testing targets unittest (direct Tryton API
> access) and scenario tests (based on proteus).
> While unittests are very powerfull to intensive test small parts of
> code, are scenario tests excellent for testing large functional
> related parts.
>
> Running tests with run-tests.py follows the rule first run all unittests
> of a module, second run the doctests[1].
>
> Is there a way to run a specific unittest after a specific scenario test
> using both the same database? (I know about setUp and tearDown…)
>
> I am asking, because I need to (unit-) test a reports ``objects`` and
> ``data`` delivered to the ``parse`` method. I can never introspect
> methods in a proteus scenario test. On the other hand using a
> unittest to create functional data like company, chart of account,
> fiscal year, invoices, accounting moves is a lot of monkey work.
> So it would be handy to have the scenario test roll out all the
> functional data and after this a unittest could use the database to
> introspect methods and check the calculations for the report.
>
> Any ideas appreciated?

I think by using this way [1] of writing reports the problem is solved
because report are just there to layout the data.

[1] https://bugs.tryton.org/issue4996


--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Sergi Almacellas Abellana]

El 29/01/16 a les 18:52, Cédric Krier ha escrit:

> On 2016-01-29 18:40, 'Udo Spallek' via tryton-dev wrote:
>> Hi,
>>
>> Tryton has two general testing targets unittest (direct Tryton API
>> access) and scenario tests (based on proteus).
>> While unittests are very powerfull to intensive test small parts of
>> code, are scenario tests excellent for testing large functional
>> related parts.
>>
>> Running tests with run-tests.py follows the rule first run all unittests
>> of a module, second run the doctests[1].
>>
>> Is there a way to run a specific unittest after a specific scenario test
>> using both the same database? (I know about setUp and tearDown…)
>>
>> I am asking, because I need to (unit-) test a reports ``objects`` and
>> ``data`` delivered to the ``parse`` method. I can never introspect
>> methods in a proteus scenario test. On the other hand using a
>> unittest to create functional data like company, chart of account,
>> fiscal year, invoices, accounting moves is a lot of monkey work.
>> So it would be handy to have the scenario test roll out all the
>> functional data and after this a unittest could use the database to
>> introspect methods and check the calculations for the report.
>>
>> Any ideas appreciated?
>
> I think by using this way [1] of writing reports the problem is solved
> because report are just there to layout the data.
>

One some of our reports we use a similar way, separting into two methods
the report generation:

- First method computes the report data [2]
- Second method generates the report with the data computed from first
method [3]

Using unittest [4] we ensure that data is correctly computed, without
using proteus and without rendering the report.

Hope it helps!


[2]
https://bitbucket.org/trytonspain/trytond-account_jasper_reports/src/c9102e9651f4629a7f224fa0a2b15cca13846037/general_ledger.py?fileviewer=file-view-default#general_ledger.py-116
[3]
https://bitbucket.org/trytonspain/trytond-account_jasper_reports/src/c9102e9651f4629a7f224fa0a2b15cca13846037/general_ledger.py?fileviewer=file-view-default#general_ledger.py-267
[4]
https://bitbucket.org/trytonspain/trytond-account_jasper_reports/src/c9102e9651f4629a7f224fa0a2b15cca13846037/tests/test_account_jasper_reports.py?at=default&fileviewer=file-view-default#test_account_jasper_reports.py-407


> [1] https://bugs.tryton.org/issue4996
>
>


--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk

[Udo Spallek]

Hi,

thanks for reply!

Mon, 1 Feb 2016 12:53:42 +0100
Sergi Almacellas Abellana <se...@koolpi.com>:

>El 29/01/16 a les 18:52, Cédric Krier ha escrit:

>> I think by using this way [1] of writing reports the problem is
>> solved because report are just there to layout the data.

Moving the report complexity to a SQL-query for a specific model of
report lines is a good idea. I guess it should be possible to add data
for the report and to check the report results in a scenario test
using proteus, since it is just a list of objects.

>One some of our reports we use a similar way, separting into two
>methods the report generation:
>- First method computes the report data [2]
>- Second method generates the report with the data computed from first
>method [3]
>Using unittest [4] we ensure that data is correctly computed, without
>using proteus and without rendering the report.

Yes, it is a good idea, too, to separate the report preparation from
execution for testing. But by using unittest I have the problem of
setting up the data needed for the report with unittest test cases.
This I would like to avoid.

Thanks!
Regards Udo

[Sergi Almacellas Abellana]

El 02/02/16 a les 19:08, 'Udo Spallek' via tryton-dev ha escrit:

>> >One some of our reports we use a similar way, separting into two
>> >methods the report generation:
>> >- First method computes the report data [2]
>> >- Second method generates the report with the data computed from first
>> >method [3]
>> >Using unittest [4] we ensure that data is correctly computed, without
>> >using proteus and without rendering the report.
> Yes, it is a good idea, too, to separate the report preparation from
> execution for testing. But by using unittest I have the problem of
> setting up the data needed for the report with unittest test cases.
> This I would like to avoid.

What problem do you have?

For me it's better to use unittest as you can run each report execution
in a single transaction, getting all the errors when something fails.
For data creation, just create a method that fills the data, and call it
on each test.

[Cédric Krier]

I don't think it makes sense to use unittest to test report.
Report are about data so they don't have often corner case so testing is
just a matter of filling some data and check the result and the
rendering (just run the Report).