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
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
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.
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
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
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
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
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
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,
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
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).
>
"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
>> 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:
>
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
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
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
16 matches
Mail list logo