#3771: Run tests on Travis
--------------------------+-------------------------
Reporter: pmav99 | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone:
Component: Tests | Version: svn-trunk
Resolution: | Keywords:
CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------
Comment (by pmav99):
Replying to [comment:4 sbl]:
> To my knowledge, most of the tests that are currently failing, started
failing due to fundamental changes from the introduction of Python 3, e.g.
everything related to bytes vs. strings...
If you scroll down far enough
[http://fatra.cnr.ncsu.edu/grassgistests/summary_report/nc/index.html
here] there is this graph:
[[Image(http://fatra.cnr.ncsu.edu/grassgistests/summary_report/nc/files_successful_plot.png)]]
Last September, indeed, there was a spike of failing tests but still ~10%
of the tests were practically always failing.
That being said, supporting both Python 2 and 3 is a requirement
encountered primarily in libraries, not applications. Applications usually
only need to support a single Python version. GRASS does provide an API,
but, at least from where I stand, it is primarily an application.
Nevertheless, the decision that GRASS 7.8 will support both Python 2 and 3
has been made and unless it is revoked, the code needs to support both
versions.
Nowadays, there is a great deal of experience in the Python community WRT
both porting code from Python 2 to 3 and to supporting both Python
versions from a single codebase. The latter usually involves using
projects like [https://pypi.org/project/six/\] and/or [https://python-
future.org/]. Using them is of course not mandatory. Most projects only
need a small part of their functionality, so they can often get away with
just a [{{compat.py}}} module and appropriate imports. On projects of
significant complexity though, it is often a good idea to use them.
Long story short, it is indeed more difficult to maintain a cross-version
compatible codebase but with some concessions it is an achievable goal.
In my humble view, the fact that the tests are failing doesn't have to do
with with Python 2 or Python 3 or even with the cross-version
compatibility. There are two rules that are pretty much unanimously
accepted in the software development industry:
1. Don't break the build.
2. You break the build, you fix it.
(obviously, running the tests is considered part of the build)
The afore-mentioned graph shows that GRASS devs don't run the tests as
part of their development routine. I argue that this needs to change.
Arguably, no one wants to wait for a long running testsuite to finish. And
that's absolutely natural. Honestly speaking, no one ''should'' have to
wait. That's what CI is for. To build the code and run the tests.
The gist of the issue here is supporting GRASS' growth. Automated builds
and improved testing procedures are a prerequisite of this goal. An
important checkpoint in this effort is achieving a green build.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3771#comment:5>
GRASS GIS <https://grass.osgeo.org>
