Hi Achim, Achim Gratz <strom...@nexgo.de> writes:
>> If anyone knows how to setup an automated tests framework for Org, >> feel free to go ahead, we will use it and monitor broken tests to >> see what's wrong in the code or in the tests or in the environment >> running the tests. > > We already have one, The test are not automatic, they are manually triggered, so we don't have an "automated tests framework" -- or am I misunderstanding what an automated test framework is? > what Nick and Sebastien are asking is not to push > commits that are known to not pass the tests. This I 100% agree with. I don't push commits that are known to me as not passing the tests :) >> Testing is a nice habit to have, but let's not make it a coercive >> pre-requisit before pushing patches. > > Why not? Any broken commits make automatic bisecting impossible and they > are a constant source of irritation for folks who forget to test their new > Org pulls before using or installing them. > >> My whole thinking here is well captured by Rich Hickey: > > The citation you gave doesn't even apply to the question at hand. It is > about writing tests, not using the tests you already have. It is about life being short and time being spent on testing vs coding. If you can come up with a pre-push hook that is clever enough to distinguish trivial-and-safe changes against those who need to be tested, please submit one. A trivial-and-safe change is either: - a change against non-code files; - a change in docstring. I don't think this is easy to do. Rich message wrt tests is: "Life is short, decide whether you want to spend it on testing or coding" -- so I think it's relevant here. I often have only 10 minutes at hand, make a few trivial changes, and push. For me, a mandatory pre-push hook running the test suite would be a useless burden for 50% of my commits. This would irritate me. We might agree to disagree on this. -- Bastien
