Replace doctest for scenario tests

[albert (Albert Cervera i Areny)]

@ced

Indeed we could just add those assert methods to trytond.tests.tools .

Thank you very much for the proposed patch.

Still, I don’t grasp what we gain by keeping doctest as is, specially if we add all those features.

After the patch is committed I understand that the only provided features by doctest are:

• Testing values without an explicit assert
• Testing exceptions without an explicit assert
• At least in theory, makes the comments (the scenario) more prominent

The first two features are provided by the assertEqual and assertRaises respectively. The latter, can be just python comments.

At the same time if I look at what is the cost of keep using rst I see:

• We need additional scripts to convert those rst into python code to have the checks pyflakes or flake8 provide. Your patch proposes what the tryton project needs, but every company and individual has its own workflows. I wouldn’t care for out of project needs if the benefits of doctest where huge but I don’t think so.
• We do not have syntax highlight. Again, the argument that it is just a tools issue may be ok for me if the benefit of the feature was huge but I don’t think so. If one wants syntax highlighting he needs to implement the tooling for heptapod, github, vim, vs code, etc. While we get them for free using standard python scripts.
• It forces all tests to add the ">>> " prefix and when you want multiple lines to add the "… ". I don’t know about others, but I need to write those prefixes for every single line of code. Maybe tools can automate part of that, but why would I want to create the tools if python scripts would essentially do the same job. Also, if I multiply that extra tooling cost for all developers here, is really all worth it?
• The argument that you’re very productive with rst is ok but I really don’t get how you’d be less productive with plain python scripts.

So, for me (and the rest of our team, and it seems for others too) it makes both writing and reading tests more complicated and also requires extra tooling. What are the real benefits?

[ced (Cédric Krier)]

@albert

Still, I don’t grasp what we gain by keeping doctest as is, specially if we add all those features.

For me the value precisely in what they do not provide.
They force to write sequential steps (aka scenario) with automatic check on each line.
Also they provide better comparison than assert* (see the Decimal precision).

And another goal is to have those scenario part of the documentation. It happens often that on this forum we lead people to read one scenario to understand how a module works.

@albert

but every company and individual has its own workflows.

That Tryton uses doctest does not force anything on any body.

@albert

We do not have syntax highlight.

Ask to your editor.

@albert

If one wants syntax highlighting he needs to implement the tooling for heptapod, github, vim, vs code, etc.

Why? He just needs for where he need it.

@albert

While we get them for free using standard python scripts.

It is not free. It is because someone has developed it.

@albert

It forces all tests

Only scenario for Tryton.

@albert

I really don’t get how you’d be less productive with plain python scripts.

Plain python scripts does not provide the tooling. You need to use unittest (see the unit) TestCase which are not sequential like scenario.
So if it is to have to write the same test on each line as docttest does, I do not see the point.

@albert

for me (and the rest of our team, and it seems for others too)

You can use what ever you want for testing your code.

@albert

reading tests more complicated

I strongly disagree. We have already provided support to people by telling them to read scenario. It never happened with TestCase.