[GRASS-dev] [GRASS GIS] #3771: Run tests on Travis

[GRASS GIS]

#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>