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 all Java projects I have
> changes that introduced them, or are we just going to accept that flaky
> > > tests get added and deal with them retroactively? I assume we could also
> > > set up some kind of CI job that would run a new test, say, 20 times and
> > > greenlight it for patches adding c
> >
> > > In addition to it’s test coverage problem, the project has a general
> > > testability problem, and I think it would be more effective to
> introduce
> > > some testing guidelines and standards that drive incremental
> improvement
> > of
>
both, instead of requiring an arbitrary code coverage metric be hit,
> which
> > doesn’t tell the whole story anyway.
> >
> > It’s not ready yet, but I’ve been putting together a testing standards
> > document for the project since bringing it up in the “Code quality,
>
ting standards
> document for the project since bringing it up in the “Code quality,
> principles and rules” email thread a week or so ago.
>
> On March 27, 2017 at 4:51:31 PM, Edward Capriolo (edlinuxg...@gmail.com)
> wrote:
> On Mon, Mar 27, 2017 at 7:03 PM, Josh McKenzie
>
doesn’t
tell the whole story anyway.
It’s not ready yet, but I’ve been putting together a testing standards document
for the project since bringing it up in the “Code quality, principles and
rules” email thread a week or so ago.
On March 27, 2017 at 4:51:31 PM, Edward Capriolo (edlinuxg
On Mon, Mar 27, 2017 at 7:03 PM, Josh McKenzie wrote:
> How do we plan on verifying #4? Also, root-cause to tie back new code that
> introduces flaky tests (i.e. passes on commit, fails 5% of the time
> thereafter) is a non-trivial pursuit (thinking #2 here), and a pretty
> common problem in this
How do we plan on verifying #4? Also, root-cause to tie back new code that
introduces flaky tests (i.e. passes on commit, fails 5% of the time
thereafter) is a non-trivial pursuit (thinking #2 here), and a pretty
common problem in this environment.
On Mon, Mar 27, 2017 at 6:51 PM, Nate McCall wro
I don't want to lose track of the original idea from François, so
let's do this formally in preparation for a vote. Having this all in
place will make transition to new testing infrastructure more
goal-oriented and keep us more focused moving forward.
Does anybody have specific feedback/discussion
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 runn
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. Mi
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 Java projects I have seen
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 Java projects I have seen, people use mock
(mockito, powermock) for dependencies. And
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 existing code, making i
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 a
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 sections
> and it'll sho
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 pul
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,
tha
As someone who spent a lot of time looking at the singletons topic in the
past, Blake brings a great perspective here. Figuring out and communicating
how best to test with the system we have (and of course incrementally
making that system easier to work with/test) seems like an achievable goal.
On
On Fri, Mar 17, 2017 at 12:33 PM, Blake Eggleston
wrote:
> 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 a
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 be
On 2017-03-16 14:51 (-0700), Qingcun Zhou wrote:
>
> When we talk about code coverage for new code, should we encourage people
> to contribute unit test cases for existing code?
>
Unit tests for existing untested code seems like something we'd welcome and
encourage.
On Fri, Mar 17, 2017 at 9:46 AM, Edward Capriolo
wrote:
>
>
> 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,
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).
>
> To back this asse
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).
To back this assertion up for awhile in that community benching different
DI fra
On Thu, Mar 16, 2017 at 5:18 PM, Jason Brown wrote:
> >> 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, 2
Performance consideration is a valid concern.
When I say "difficult to write unit test cases", I mean sometimes you need
to make method/variable package private, or create a package private
constructor so that you can inject some internal states, etc. This is more
like "annoying" if it's not "diff
"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 ex
>> 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
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 wrote:
>
> >
> >
> > On 2017-03-16 10:3
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 we don't care
> about test failures, then we
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 failing test
> carries
Hi Dev,
What principles do we have? How do we implement them?
Our team has been evaluating 3.0.x and 3.x for a large production deployment.
We have noticed broken tests and have been working on several patches.
However, large parts of the code base are wildly untested, which makes new
contri
33 matches
Mail list logo
