On 07 Feb 14:25, Sharoon Thomas wrote: > On 02/07, Cédric Krier wrote: > > On 07 Feb 12:34, Sharoon Thomas wrote: > > > On 02/06, Sergi Almacellas Abellana wrote: > > > > I also managed to run coverage to ensure that module coverage is over a > > > > specific % (75% on my case, but can be customized per module). Patch is > > > > here[3] (and here[4] is run by default). The output is also available on > > > > drone [5]. Do you think this is also interesting to add? > > > > > > Coverage % could be a vanity metric but we have been trying to achieve > > > 100% coverage for critical modules and a significantly high coverage > > > for others. This has certainly improved the quality of the code and if > > > the tests are written well (not just for the sake of coverage) there are > > > hardly any maintenance issues. > > > > Base on what? Where do you find a correlation between coverage and > > quality? How do you achieve "not just for the sake of coverage"? Which > > threshold is it? > > Statement coverage testing is a good measure of what **isn't** being tested > in your code. Knowing what is tested and what is not by a test suite and > seeing if a patch reduces code coverage is important to maintaining the > quality of the codebase.
As you said it is a *measure* so it doesn't have its place on CI. > I hope you remember that there were branches of code in the ModelSQL.write > which could never be reached when we tested for coverage. So what? What is your plan to improve that? "Running coverage"? Why don't you run it now? > > What the point of having failure like that: > > > > https://coveralls.io/r/openlabs/nereid-webshop > > This is not a failure. OK so a big red label is not a failure. So this tools is even worst than what I thought. > > https://travis-ci.org/openlabs/nereid-webshop/jobs/49836710 > > Those have to be fixed. Flake8 had an update today. Flake8 gives us a > coding style to follow that most python programmers can follow. It is > not what Cedrik thinks is beautiful or I think is beautiful. This makes flake8 requirement even worst, I don't want to have to change code to please flake8. And adding flake8 to CI will make required to do that ASAP otherwise the CI will be useless by reporting false failing. > > As usual you are just following to mass without thinking exactly what it > > implies and what it brings. > > I'd prefer "Tested code that works" and "Tested code that breaks" to > "Untested code that works". Without coverage you have no way of knowing > which part is tested to begin with. You are welcomed to run coverage in your developement process. I even encourage everyone to do it because it is one of the possible measure that can give you some information about the quality. > If preferring to know which part of > the code is tested is "mass thinking", I guess I am with the mass and > not with you. You don't understand at all my thinking. I never said to not run coverage tools on trytond. I said it is not the job of the CI, it must not fail the CI, it must not prevent to develop. > PS: I don't intend on changing how you think about this. So you admit to not have good argument. > This is a > public mailing list About Tryton developement and nothing else. > and my mail only explains why we use coverage and > flake8 to provide better quality software to our customers. Which is clearly showed on the very first repository I pick from you. > If you think > these tools don't help you in improving software quality, so be it. Never say that, re-read my emails. PS: My name is Cédric. -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
pgp7GbXmbDmsf.pgp
Description: PGP signature
