Re: Code quality, principles and rules

2017-03-29 Thread Edward Capriolo
On Sat, Mar 18, 2017 at 9:21 PM, Qingcun Zhou wrote: > I wanted to contribute some unit test cases. However the unit test approach > in Cassandra seems weird to me after looking into some examples. Not sure > if anyone else has the same feeling. > > Usually, at least for

Re: Code quality, principles and rules

2017-03-22 Thread Michael Shuler
On 03/22/2017 12:41 PM, François Deliège wrote: > A first actionable step is to increase the visibility of the test > coverage. Ideally this would be integrated in the Jenkins run on > Apache. Michael Shuler, is this something you can take a look at? > Let me know if we can help. We've been

Re: Code quality, principles and rules

2017-03-22 Thread François Deliège
Thanks everybody for chiming in. I have not heard any concerns about the rules, so I’d like to move forward with some concrete steps in that direction. A first actionable step is to increase the visibility of the test coverage. Ideally this would be integrated in the Jenkins run on Apache.

Re: Code quality, principles and rules

2017-03-19 Thread Edward Capriolo
On Saturday, March 18, 2017, Qingcun Zhou wrote: > I wanted to contribute some unit test cases. However the unit test approach > in Cassandra seems weird to me after looking into some examples. Not sure > if anyone else has the same feeling. > > Usually, at least for all

Re: Code quality, principles and rules

2017-03-17 Thread Jeremy Hanna
https://issues.apache.org/jira/browse/CASSANDRA-7837 may be some interesting context regarding what's been worked on to get rid of singletons and static initialization. > On Mar 17, 2017, at 4:47 PM, Jonathan Haddad wrote: > > I'd like to think that if someone refactors

Re: Code quality, principles and rules

2017-03-17 Thread Jonathan Haddad
I'd like to think that if someone refactors existing code, making it more testable (with tests, of course) it should be acceptable on it's own merit. In fact, in my opinion it sometimes makes more sense to do these types of refactorings for the sole purpose of improving stability and testability

Re: Code quality, principles and rules

2017-03-17 Thread Edward Capriolo
On Fri, Mar 17, 2017 at 2:31 PM, Jason Brown wrote: > To François's point about code coverage for new code, I think this makes a > lot of sense wrt large features (like the current work on 8457/12229/9754). > It's much simpler to (mentally, at least) isolate those changed

Re: Code quality, principles and rules

2017-03-17 Thread benjamin roth
I think you can refactor any project with little risk and increase test coverage. What is needed: Rules. Discipline. Perseverance. Small iterations. Small iterations. Small iterations. - Refactor in the smallest possible unit - Split large classes into smaller ones. Remove god classes by

Re: Code quality, principles and rules

2017-03-17 Thread Jason Brown
To François's point about code coverage for new code, I think this makes a lot of sense wrt large features (like the current work on 8457/12229/9754). It's much simpler to (mentally, at least) isolate those changed sections and it'll show up better in a code coverage report. With small patches,

Re: Code quality, principles and rules

2017-03-17 Thread Blake Eggleston
I think we’re getting a little ahead of ourselves talking about DI frameworks. Before that even becomes something worth talking about, we’d need to have made serious progress on un-spaghettifying Cassandra in the first place. It’s an extremely tall order. Adding a DI framework right now would

Re: Code quality, principles and rules

2017-03-17 Thread Edward Capriolo
On Fri, Mar 17, 2017 at 6:41 AM, Ryan Svihla wrote: > Different DI frameworks have different initialization costs, even inside of > spring even depending on how you wire up dependencies (did it use autowire > with reflection, parse a giant XML of explicit dependencies, etc). >

Re: Code quality, principles and rules

2017-03-16 Thread DuyHai Doan
"Otherwise it'll be difficult to write unit test cases." Having to pull in dependency injection framework to make unit testing easier is generally a sign of code design issue. With constructor injection & other techniques, there is more than enough to unit test your code without having to pull

Re: Code quality, principles and rules

2017-03-16 Thread Jason Brown
>> do we have plan to integrate with a dependency injection framework? No, we (the maintainers) have been pretty much against more frameworks due to performance reasons, overhead, and dependency management problems. On Thu, Mar 16, 2017 at 2:04 PM, Qingcun Zhou wrote: >

Re: Code quality, principles and rules

2017-03-16 Thread Qingcun Zhou
Since we're here, do we have plan to integrate with a dependency injection framework like Dagger2? Otherwise it'll be difficult to write unit test cases. On Thu, Mar 16, 2017 at 1:16 PM, Edward Capriolo wrote: > On Thu, Mar 16, 2017 at 3:10 PM, Jeff Jirsa

Re: Code quality, principles and rules

2017-03-16 Thread Edward Capriolo
On Thu, Mar 16, 2017 at 3:10 PM, Jeff Jirsa wrote: > > > On 2017-03-16 10:32 (-0700), François Deliège > wrote: > > > > To get this started, here is an initial proposal: > > > > Principles: > > > > 1. Tests always pass. This is the starting point. If

Re: Code quality, principles and rules

2017-03-16 Thread Jeff Jirsa
On 2017-03-16 10:32 (-0700), François Deliège wrote: > > To get this started, here is an initial proposal: > > Principles: > > 1. Tests always pass. This is the starting point. If we don't care about > test failures, then we should stop writing tests. A recurring