#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>
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev