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
Yes, failed test results need to be looked at by someone. But this is
already the case and won't change no matter if we run tests for each
patch and branch, or just once a day for a single dev branch. Having to
figure out which commit exactly causes the regression would take some
additional effort,
"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