You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Kirk Lund <kl...@pivotal.io> on 2016/04/05 02:25:35 UTC
Removing hydra.Log from dunit tests
I just hit this in two different dunit tests and easily replaced hydra.Log
with LogWriterUtils.
1) Remove "import hydra.Log"
2) Add "import static com.gemstone.gemfire.test.dunit.LogWriterUtils.*;"
3) Replace "Log.getLogWriter()" with "getLogWriter()"
I'm not sweeping through all tests to do this, but if you run into a dunit
with hydra.Log please replace it with LogWriterUtils or Logger or
System.out statements.
If anyone feels strongly about standardizing on Logger or System.out
statements (or even opinions on not having any output statements in tests)
please weigh in.
-Kirk
Re: Removing hydra.Log from dunit tests
Posted by Kirk Lund <kl...@pivotal.io>.
During some of my dunit refactorings I noticed that quite a few dunits have
a LOT of LogWriter statements. Removing most of these might be one way to
speed up distributedTest tasks.
-Kirk
On Tue, Apr 5, 2016 at 11:31 AM, John Blum <jb...@pivotal.io> wrote:
> Agreed, logging should be very minimal and with purpose. Debugging using
> the debugger is the most reliable and efficient means.
>
> On Tue, Apr 5, 2016 at 11:29 AM, Dan Smith <ds...@pivotal.io> wrote:
>
> > +1 for using using an actual "Logger" if you need to leave a log in a
> test
> > for some reason. But I also agree with Kareem that the tests generally
> > shouldn't have log statements unless you are trying to debug the test.
> >
> > -Dan
> >
> > On Tue, Apr 5, 2016 at 11:05 AM, John Blum <jb...@pivotal.io> wrote:
> >
> > > +1 I know when you set GemFire's log level to "config", it can take the
> > > tests much longer to run, and it consumes more resources.
> > >
> > > As far as logging approach, using an actual "Logger" makes the most
> sense
> > > in order to control what gets logged along with the level of detail.
> > > System.out's are much too crude to be useful in any context. If you
> are
> > > having to resort to System.out, then you might as well use the
> debugger.
> > >
> > > On Tue, Apr 5, 2016 at 10:04 AM, kareem shabazz <
> > kareem.shabazz@gmail.com>
> > > wrote:
> > >
> > > > Logging should be purely diagnostic in tests and not be counted on in
> > the
> > > > day-to-day running of tests. If a test fails and one cannot diagnose
> > why
> > > > then logging can b employed otherwise the extra IO should b avoided.
> > And
> > > in
> > > > the case of dunit tests where multiple VMs can b logging it can end
> up
> > > > being confusing if there is no inherent order or thread marker per
> > > > logger/println.
> > > >
> > > > --
> > > > Kareem
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Apr 4, 2016 at 5:25 PM -0700, "Kirk Lund" <kl...@pivotal.io>
> > > > wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I just hit this in two different dunit tests and easily replaced
> > > hydra.Log
> > > > with LogWriterUtils.
> > > >
> > > > 1) Remove "import hydra.Log"
> > > > 2) Add "import static
> > com.gemstone.gemfire.test.dunit.LogWriterUtils.*;"
> > > > 3) Replace "Log.getLogWriter()" with "getLogWriter()"
> > > >
> > > > I'm not sweeping through all tests to do this, but if you run into a
> > > dunit
> > > > with hydra.Log please replace it with LogWriterUtils or Logger or
> > > > System.out statements.
> > > >
> > > > If anyone feels strongly about standardizing on Logger or System.out
> > > > statements (or even opinions on not having any output statements in
> > > tests)
> > > > please weigh in.
> > > >
> > > > -Kirk
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > -John
> > > 503-504-8657
> > > john.blum10101 (skype)
> > >
> >
>
>
>
> --
> -John
> 503-504-8657
> john.blum10101 (skype)
>
Re: Removing hydra.Log from dunit tests
Posted by John Blum <jb...@pivotal.io>.
Agreed, logging should be very minimal and with purpose. Debugging using
the debugger is the most reliable and efficient means.
On Tue, Apr 5, 2016 at 11:29 AM, Dan Smith <ds...@pivotal.io> wrote:
> +1 for using using an actual "Logger" if you need to leave a log in a test
> for some reason. But I also agree with Kareem that the tests generally
> shouldn't have log statements unless you are trying to debug the test.
>
> -Dan
>
> On Tue, Apr 5, 2016 at 11:05 AM, John Blum <jb...@pivotal.io> wrote:
>
> > +1 I know when you set GemFire's log level to "config", it can take the
> > tests much longer to run, and it consumes more resources.
> >
> > As far as logging approach, using an actual "Logger" makes the most sense
> > in order to control what gets logged along with the level of detail.
> > System.out's are much too crude to be useful in any context. If you are
> > having to resort to System.out, then you might as well use the debugger.
> >
> > On Tue, Apr 5, 2016 at 10:04 AM, kareem shabazz <
> kareem.shabazz@gmail.com>
> > wrote:
> >
> > > Logging should be purely diagnostic in tests and not be counted on in
> the
> > > day-to-day running of tests. If a test fails and one cannot diagnose
> why
> > > then logging can b employed otherwise the extra IO should b avoided.
> And
> > in
> > > the case of dunit tests where multiple VMs can b logging it can end up
> > > being confusing if there is no inherent order or thread marker per
> > > logger/println.
> > >
> > > --
> > > Kareem
> > >
> > >
> > >
> > >
> > > On Mon, Apr 4, 2016 at 5:25 PM -0700, "Kirk Lund" <kl...@pivotal.io>
> > > wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > I just hit this in two different dunit tests and easily replaced
> > hydra.Log
> > > with LogWriterUtils.
> > >
> > > 1) Remove "import hydra.Log"
> > > 2) Add "import static
> com.gemstone.gemfire.test.dunit.LogWriterUtils.*;"
> > > 3) Replace "Log.getLogWriter()" with "getLogWriter()"
> > >
> > > I'm not sweeping through all tests to do this, but if you run into a
> > dunit
> > > with hydra.Log please replace it with LogWriterUtils or Logger or
> > > System.out statements.
> > >
> > > If anyone feels strongly about standardizing on Logger or System.out
> > > statements (or even opinions on not having any output statements in
> > tests)
> > > please weigh in.
> > >
> > > -Kirk
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > --
> > -John
> > 503-504-8657
> > john.blum10101 (skype)
> >
>
--
-John
503-504-8657
john.blum10101 (skype)
Re: Removing hydra.Log from dunit tests
Posted by Dan Smith <ds...@pivotal.io>.
+1 for using using an actual "Logger" if you need to leave a log in a test
for some reason. But I also agree with Kareem that the tests generally
shouldn't have log statements unless you are trying to debug the test.
-Dan
On Tue, Apr 5, 2016 at 11:05 AM, John Blum <jb...@pivotal.io> wrote:
> +1 I know when you set GemFire's log level to "config", it can take the
> tests much longer to run, and it consumes more resources.
>
> As far as logging approach, using an actual "Logger" makes the most sense
> in order to control what gets logged along with the level of detail.
> System.out's are much too crude to be useful in any context. If you are
> having to resort to System.out, then you might as well use the debugger.
>
> On Tue, Apr 5, 2016 at 10:04 AM, kareem shabazz <ka...@gmail.com>
> wrote:
>
> > Logging should be purely diagnostic in tests and not be counted on in the
> > day-to-day running of tests. If a test fails and one cannot diagnose why
> > then logging can b employed otherwise the extra IO should b avoided. And
> in
> > the case of dunit tests where multiple VMs can b logging it can end up
> > being confusing if there is no inherent order or thread marker per
> > logger/println.
> >
> > --
> > Kareem
> >
> >
> >
> >
> > On Mon, Apr 4, 2016 at 5:25 PM -0700, "Kirk Lund" <kl...@pivotal.io>
> > wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > I just hit this in two different dunit tests and easily replaced
> hydra.Log
> > with LogWriterUtils.
> >
> > 1) Remove "import hydra.Log"
> > 2) Add "import static com.gemstone.gemfire.test.dunit.LogWriterUtils.*;"
> > 3) Replace "Log.getLogWriter()" with "getLogWriter()"
> >
> > I'm not sweeping through all tests to do this, but if you run into a
> dunit
> > with hydra.Log please replace it with LogWriterUtils or Logger or
> > System.out statements.
> >
> > If anyone feels strongly about standardizing on Logger or System.out
> > statements (or even opinions on not having any output statements in
> tests)
> > please weigh in.
> >
> > -Kirk
> >
> >
> >
> >
> >
> >
>
>
> --
> -John
> 503-504-8657
> john.blum10101 (skype)
>
Re: Removing hydra.Log from dunit tests
Posted by John Blum <jb...@pivotal.io>.
+1 I know when you set GemFire's log level to "config", it can take the
tests much longer to run, and it consumes more resources.
As far as logging approach, using an actual "Logger" makes the most sense
in order to control what gets logged along with the level of detail.
System.out's are much too crude to be useful in any context. If you are
having to resort to System.out, then you might as well use the debugger.
On Tue, Apr 5, 2016 at 10:04 AM, kareem shabazz <ka...@gmail.com>
wrote:
> Logging should be purely diagnostic in tests and not be counted on in the
> day-to-day running of tests. If a test fails and one cannot diagnose why
> then logging can b employed otherwise the extra IO should b avoided. And in
> the case of dunit tests where multiple VMs can b logging it can end up
> being confusing if there is no inherent order or thread marker per
> logger/println.
>
> --
> Kareem
>
>
>
>
> On Mon, Apr 4, 2016 at 5:25 PM -0700, "Kirk Lund" <kl...@pivotal.io>
> wrote:
>
>
>
>
>
>
>
>
>
>
> I just hit this in two different dunit tests and easily replaced hydra.Log
> with LogWriterUtils.
>
> 1) Remove "import hydra.Log"
> 2) Add "import static com.gemstone.gemfire.test.dunit.LogWriterUtils.*;"
> 3) Replace "Log.getLogWriter()" with "getLogWriter()"
>
> I'm not sweeping through all tests to do this, but if you run into a dunit
> with hydra.Log please replace it with LogWriterUtils or Logger or
> System.out statements.
>
> If anyone feels strongly about standardizing on Logger or System.out
> statements (or even opinions on not having any output statements in tests)
> please weigh in.
>
> -Kirk
>
>
>
>
>
>
--
-John
503-504-8657
john.blum10101 (skype)
Re: Removing hydra.Log from dunit tests
Posted by kareem shabazz <ka...@gmail.com>.
Logging should be purely diagnostic in tests and not be counted on in the day-to-day running of tests. If a test fails and one cannot diagnose why then logging can b employed otherwise the extra IO should b avoided. And in the case of dunit tests where multiple VMs can b logging it can end up being confusing if there is no inherent order or thread marker per logger/println.
--
Kareem
On Mon, Apr 4, 2016 at 5:25 PM -0700, "Kirk Lund" <kl...@pivotal.io> wrote:
I just hit this in two different dunit tests and easily replaced hydra.Log
with LogWriterUtils.
1) Remove "import hydra.Log"
2) Add "import static com.gemstone.gemfire.test.dunit.LogWriterUtils.*;"
3) Replace "Log.getLogWriter()" with "getLogWriter()"
I'm not sweeping through all tests to do this, but if you run into a dunit
with hydra.Log please replace it with LogWriterUtils or Logger or
System.out statements.
If anyone feels strongly about standardizing on Logger or System.out
statements (or even opinions on not having any output statements in tests)
please weigh in.
-Kirk