Testing script

[navjotk]

Looking at the number of errors that creeped in to my commits, it might be a good idea to have a testing script on the pre-commit hook. This could prevent builds that would fail from even going through and probably reduce the number of error-correction commits in the future. Does anyone think this might be a good idea to have inside the repo?

[ggorman]

I am not sure I understand. Travis already runs on branches with pull requests, telling you if it is clear to merge or not. Shouldn't this do all the work for you?

[navjotk]

A local version of the tests that travis carries out would reduce commit clutter on the repository and save development time. I already made a shell script to do this for me, seeing the number of mistakes I made during this work. Just wondering whether this would be helpful to others and should be on the repository.

[ggorman]

I do think a "make test" is a good idea.

As for commit clutter, I think that is an orthogonal issue and Michael will delight in the idea of everyone learning to rebase and tide up commits ;-)

[mlange05]

I think running the full test suite as a pre-commit hook is a bit overkill, since it takes a few minutes. Then again running things like flake8 and maybe one example from the README could be useful for developers to avoid errors. That is everyone's choice though, and sharing helpful scripts is always a good thing (not sure where the most appropriate place for this is though).

As for commit clutter I strongly encourage everybody to use git's "interactive rebase" feature to create clean and readable commit histories. Our current history is reasonably short still and we have the chance of actually having a meaningful history that helps people understand the code.