Re: [DISCUSS] test code style (particularly logging)
Most of these logWriter or logger usages are in larger end-to-end tests that were written before we could using IDE debuggers on our tests. With a debugger, I don't want to see more output from the test so I tend to delete all such System.out.printlns or LogWriter/Logger usage. My recommendation is to delete all extra System.out.printlns AND LogWriter/Logger usages unless it's part of the test itself. If you think the line is useful, then would it be sufficient as a comment? If not then maybe the test is too long, doing too much and should be exploded into several easier to debug test methods with more narrow focus. Remember, a single test that does a lot and has tons of assertions is an anti-pattern. It's better to split that test out into many tests such that by seeing that the test failed, you either know exactly what broke without digging too much or at least have a pretty good idea where to dig. Sure, there's a balance to strike especially in end-to-end tests but if the test method scrolls along for many screens, then most likely it's doing too much and the author(s) added logging to compensate for this. On Thu, Sep 20, 2018 at 2:10 PM, Darrel Schneider wrote: > For simple single threaded tests System.out would do the job. > For a multi-threaded test I have found the logging framework to be helpful > because of the thread id and the timestamps. > > > On Thu, Sep 20, 2018 at 1:50 PM Dale Emery wrote: > > > As long as the stdout is available in the test results, I’m more than > > happy to avoid coupling the tests to the product logging code. > > > > > On Sep 20, 2018, at 1:39 PM, Galen O'Sullivan > > wrote: > > > > > > I was reviewing a PR recently and noticed that we have some test code > > that > > > uses Logger (or LogWriter). If I understand correctly, anything logged > to > > > stdout will be included in the test output, and anything logged in a > > DUnit > > > VM will be logged with the appropriate VM number prepended in the > output. > > > Because logging is coupled to product code, I propose we log all test > > > output to standard out (using System.out.println or such). I also > propose > > > we add this to the Geode style guide. > > > > > > Thoughts/questions/objections? > > > > > > Thanks, > > > Galen > > > > > > — > > Dale Emery > > dem...@pivotal.io > > > > >
Re: [DISCUSS] test code style (particularly logging)
Exactly what Kirk said! > On Sep 21, 2018, at 10:34 AM, Kirk Lund wrote: > > Most of these logWriter or logger usages are in larger end-to-end tests > that were written before we could using IDE debuggers on our tests. With a > debugger, I don't want to see more output from the test so I tend to delete > all such System.out.printlns or LogWriter/Logger usage. > > My recommendation is to delete all extra System.out.printlns AND > LogWriter/Logger usages unless it's part of the test itself. If you think > the line is useful, then would it be sufficient as a comment? If not then > maybe the test is too long, doing too much and should be exploded into > several easier to debug test methods with more narrow focus. > > Remember, a single test that does a lot and has tons of assertions is an > anti-pattern. It's better to split that test out into many tests such that > by seeing that the test failed, you either know exactly what broke without > digging too much or at least have a pretty good idea where to dig. Sure, > there's a balance to strike especially in end-to-end tests but if the test > method scrolls along for many screens, then most likely it's doing too much > and the author(s) added logging to compensate for this. > > On Thu, Sep 20, 2018 at 2:10 PM, Darrel Schneider > wrote: > >> For simple single threaded tests System.out would do the job. >> For a multi-threaded test I have found the logging framework to be helpful >> because of the thread id and the timestamps. >> >> >>> On Thu, Sep 20, 2018 at 1:50 PM Dale Emery wrote: >>> >>> As long as the stdout is available in the test results, I’m more than >>> happy to avoid coupling the tests to the product logging code. >>> On Sep 20, 2018, at 1:39 PM, Galen O'Sullivan >>> wrote: I was reviewing a PR recently and noticed that we have some test code >>> that uses Logger (or LogWriter). If I understand correctly, anything logged >> to stdout will be included in the test output, and anything logged in a >>> DUnit VM will be logged with the appropriate VM number prepended in the >> output. Because logging is coupled to product code, I propose we log all test output to standard out (using System.out.println or such). I also >> propose we add this to the Geode style guide. Thoughts/questions/objections? Thanks, Galen >>> >>> >>> — >>> Dale Emery >>> dem...@pivotal.io >>> >>> >>
Develop is broken
Develop is broken due to geode-junit:checkPom because we excluded a bad dependency. Now I'm trying to run checkPom but this produces an error for (see below). How do I run checkPom locally? /Users/klund/dev/geode [515]$ ./gradlew geode-junit:checkPom Starting a Gradle Daemon, 1 incompatible Daemon could not be reused, use --status for details FAILURE: Build failed with an exception. * What went wrong: A problem occurred configuring root project 'geode'. > Could not open proj remapped class cache for 4mjlq6uuhkn837v4mkpfamjj0 (/Users/klund/.gradle/caches/4.10.1/scripts-remapped/build_dhiaf3jsqzzh3uiatuthf4d4m/4mjlq6uuhkn837v4mkpfamjj0/proj824f8d1874ee655abbb652ed370f985b). > Could not open proj generic class cache for build file '/Users/klund/dev/geode/build.gradle' (/Users/klund/.gradle/caches/4.10.1/scripts/4mjlq6uuhkn837v4mkpfamjj0/proj/proj824f8d1874ee655abbb652ed370f985b). > java.io.IOException: Failed to list contents of /Users/klund/.gradle/caches/4.10.1/scripts/4mjlq6uuhkn837v4mkpfamjj0/proj/proj824f8d1874ee655abbb652ed370f985b/classes * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. * Get more help at https://help.gradle.org BUILD FAILED in 7s
Re: Develop is broken
We killed the Gradle Daemon and pushed a fix for the geode-junit:checkPom error. Develop should be building cleanly again. On Fri, Sep 21, 2018 at 11:42 AM, Kirk Lund wrote: > Develop is broken due to geode-junit:checkPom because we excluded a bad > dependency. > > Now I'm trying to run checkPom but this produces an error for (see below). > How do I run checkPom locally? > > /Users/klund/dev/geode [515]$ ./gradlew > geode-junit:checkPom > Starting a Gradle Daemon, 1 incompatible Daemon could not be reused, use > --status for details > > FAILURE: Build failed with an exception. > > * What went wrong: > A problem occurred configuring root project 'geode'. > > Could not open proj remapped class cache for 4mjlq6uuhkn837v4mkpfamjj0 > (/Users/klund/.gradle/caches/4.10.1/scripts-remapped/build_ > dhiaf3jsqzzh3uiatuthf4d4m/4mjlq6uuhkn837v4mkpfamjj0/ > proj824f8d1874ee655abbb652ed370f985b). >> Could not open proj generic class cache for build file > '/Users/klund/dev/geode/build.gradle' (/Users/klund/.gradle/caches/ > 4.10.1/scripts/4mjlq6uuhkn837v4mkpfamjj0/proj/ > proj824f8d1874ee655abbb652ed370f985b). > > java.io.IOException: Failed to list contents of > /Users/klund/.gradle/caches/4.10.1/scripts/4mjlq6uuhkn837v4mkpfamjj0/proj/ > proj824f8d1874ee655abbb652ed370f985b/classes > > * Try: > Run with --stacktrace option to get the stack trace. Run with --info or > --debug option to get more log output. Run with --scan to get full insights. > > * Get more help at https://help.gradle.org > > BUILD FAILED in 7s > >
Re: [DISCUSS] test code style (particularly logging)
In general I agree. I’m an author of the PR that triggered this thread. That PR specifically prints new information to help diagnose an intermittent CI failure in a DistributedTest test, which we have been unable to reproduce outside of CI. Our working hypothesis is that an action initiated at the end of a test sometimes continues beyond the end of the test, interfering with the next test. The information we’re printing is designed to help test our hypothesis. In another case, I added printouts to report progress through a multi-threaded “unit” test, where the test establishes a specific interleaving between threads. That test also was difficult to reproduce outside of CI. We’re confident that we’ve fixed the original problem in the test, but if we’re wrong, the printouts give essential information to whoever has to diagnose the next failure in CI. In each of these cases, we originally used logging to write the new information. In response to Galen’s comments and other advice in this thread, we’ve switched to printouts, to reduce the tests’ unnecessary dependence on product code that isn’t relevant to the test. All of that said, I also strongly prefer tests that are small enough, focused enough, and clear enough that logs/printouts are unnecessary. — Dale Emery dem...@pivotal.io > On Sep 21, 2018, at 10:34 AM, Kirk Lund wrote: > > Most of these logWriter or logger usages are in larger end-to-end tests > that were written before we could using IDE debuggers on our tests. With a > debugger, I don't want to see more output from the test so I tend to delete > all such System.out.printlns or LogWriter/Logger usage. > > My recommendation is to delete all extra System.out.printlns AND > LogWriter/Logger usages unless it's part of the test itself. If you think > the line is useful, then would it be sufficient as a comment? If not then > maybe the test is too long, doing too much and should be exploded into > several easier to debug test methods with more narrow focus. > > Remember, a single test that does a lot and has tons of assertions is an > anti-pattern. It's better to split that test out into many tests such that > by seeing that the test failed, you either know exactly what broke without > digging too much or at least have a pretty good idea where to dig. Sure, > there's a balance to strike especially in end-to-end tests but if the test > method scrolls along for many screens, then most likely it's doing too much > and the author(s) added logging to compensate for this. > > On Thu, Sep 20, 2018 at 2:10 PM, Darrel Schneider > wrote: > >> For simple single threaded tests System.out would do the job. >> For a multi-threaded test I have found the logging framework to be helpful >> because of the thread id and the timestamps. >> >> >> On Thu, Sep 20, 2018 at 1:50 PM Dale Emery wrote: >> >>> As long as the stdout is available in the test results, I’m more than >>> happy to avoid coupling the tests to the product logging code. >>> On Sep 20, 2018, at 1:39 PM, Galen O'Sullivan >>> wrote: I was reviewing a PR recently and noticed that we have some test code >>> that uses Logger (or LogWriter). If I understand correctly, anything logged >> to stdout will be included in the test output, and anything logged in a >>> DUnit VM will be logged with the appropriate VM number prepended in the >> output. Because logging is coupled to product code, I propose we log all test output to standard out (using System.out.println or such). I also >> propose we add this to the Geode style guide. Thoughts/questions/objections? Thanks, Galen >>> >>> >>> — >>> Dale Emery >>> dem...@pivotal.io >>> >>> >>
Re: [DISCUSS] test code style (particularly logging)
I would probably lean towards using System.out.println in a non-end-to-end test and using Logger in an end-to-end test that's already using our logging system. My only argument against using System.out.println in an end-to-end test is that it can easily get lost or incorrectly interleaved in the output from the test. Either approach is ok with me for your purposes though. On Fri, Sep 21, 2018 at 11:57 AM, Dale Emery wrote: > In general I agree. > > I’m an author of the PR that triggered this thread. That PR specifically > prints new information to help diagnose an intermittent CI failure in a > DistributedTest test, which we have been unable to reproduce outside of CI. > Our working hypothesis is that an action initiated at the end of a test > sometimes continues beyond the end of the test, interfering with the next > test. The information we’re printing is designed to help test our > hypothesis. > > In another case, I added printouts to report progress through a > multi-threaded “unit” test, where the test establishes a specific > interleaving between threads. That test also was difficult to reproduce > outside of CI. We’re confident that we’ve fixed the original problem in the > test, but if we’re wrong, the printouts give essential information to > whoever has to diagnose the next failure in CI. > > In each of these cases, we originally used logging to write the new > information. In response to Galen’s comments and other advice in this > thread, we’ve switched to printouts, to reduce the tests’ unnecessary > dependence on product code that isn’t relevant to the test. > > All of that said, I also strongly prefer tests that are small enough, > focused enough, and clear enough that logs/printouts are unnecessary. > > — > Dale Emery > dem...@pivotal.io > > > On Sep 21, 2018, at 10:34 AM, Kirk Lund wrote: > > > > Most of these logWriter or logger usages are in larger end-to-end tests > > that were written before we could using IDE debuggers on our tests. With > a > > debugger, I don't want to see more output from the test so I tend to > delete > > all such System.out.printlns or LogWriter/Logger usage. > > > > My recommendation is to delete all extra System.out.printlns AND > > LogWriter/Logger usages unless it's part of the test itself. If you think > > the line is useful, then would it be sufficient as a comment? If not then > > maybe the test is too long, doing too much and should be exploded into > > several easier to debug test methods with more narrow focus. > > > > Remember, a single test that does a lot and has tons of assertions is an > > anti-pattern. It's better to split that test out into many tests such > that > > by seeing that the test failed, you either know exactly what broke > without > > digging too much or at least have a pretty good idea where to dig. Sure, > > there's a balance to strike especially in end-to-end tests but if the > test > > method scrolls along for many screens, then most likely it's doing too > much > > and the author(s) added logging to compensate for this. > > > > On Thu, Sep 20, 2018 at 2:10 PM, Darrel Schneider > > > wrote: > > > >> For simple single threaded tests System.out would do the job. > >> For a multi-threaded test I have found the logging framework to be > helpful > >> because of the thread id and the timestamps. > >> > >> > >> On Thu, Sep 20, 2018 at 1:50 PM Dale Emery wrote: > >> > >>> As long as the stdout is available in the test results, I’m more than > >>> happy to avoid coupling the tests to the product logging code. > >>> > On Sep 20, 2018, at 1:39 PM, Galen O'Sullivan > >>> wrote: > > I was reviewing a PR recently and noticed that we have some test code > >>> that > uses Logger (or LogWriter). If I understand correctly, anything logged > >> to > stdout will be included in the test output, and anything logged in a > >>> DUnit > VM will be logged with the appropriate VM number prepended in the > >> output. > Because logging is coupled to product code, I propose we log all test > output to standard out (using System.out.println or such). I also > >> propose > we add this to the Geode style guide. > > Thoughts/questions/objections? > > Thanks, > Galen > >>> > >>> > >>> — > >>> Dale Emery > >>> dem...@pivotal.io > >>> > >>> > >> > >
[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #1047 was SUCCESSFUL (with 2456 tests). Change made by Mark Paluch.
--- Spring Data GemFire > Nightly-ApacheGeode > #1047 was successful. --- Scheduled with changes by Mark Paluch. 2458 tests in total. https://build.spring.io/browse/SGF-NAG-1047/ -- Code Changes -- Mark Paluch (05099eb2e59a63344b9198632480c3823c0970b7): >DATAGEODE-141 - After release cleanups. Mark Paluch (a407e22da773edf4e0dab7878791935e1eafc0f8): >DATAGEODE-141 - Updated changelog. Mark Paluch (5bb1fca22512d9b92f265b4b23cfc77ccc1e1069): >DATAGEODE-141 - Release version 2.1 GA (Lovelace). -- This message is automatically generated by Atlassian Bamboo
Spring Boot for Apache Geode 1.0.0.M3 Released!
It is my pleasure to announce [1] the release of *Spring Boot for Apache Geode* 1.0.0.M3. This release builds on the latest GA version of *Spring Boot*, 2.0.5.RELEASE, and adds extensive support for using *Spring Boot Actuator* [2] (specifically, providing HealthIndicators [3]) with Apache Geode, to assess the state and health of many Geode components (e.g. Regions, Indexes, etc) at runtime. More details can be found in the documentation, beginning here [3]. Feedback welcomed! Regards, -- -John [1] https://spring.io/blog/2018/09/22/spring-boot-for-apache-geode-pivotal-gemfire-1-0-0-m3-released [2] https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready.html [3] https://docs.spring.io/autorepo/docs/spring-boot-data-geode-build/1.0.0.BUILD-SNAPSHOT/reference/htmlsingle/#actuator
