#TDD, #CodeReview and #ContinuousIntegration in action - here is how with @marcandsweep we develop new features in #JaCoCo (jacoco.org/jacoco/):
as an example let's have a look at github.com/jacoco/jacoco/… …
as an example let's have a look at github.com/jacoco/jacoco/… …
… first we add high level "validation" test to study desired behavior, this test targets Records (openjdk.java.net/jeps/359) that are #JDK14 Preview Feature (openjdk.java.net/jeps/12),
so build fails locally, but only on JDK14 …
so build fails locally, but only on JDK14 …
… yes - locally for development we have many #Java versions installed … 
… and that's also why for #ContinuousIntegration we run builds with ten #JDK versions - from #JDK5 up to Early Access builds of unreleased #JDK14 (jdk.java.net/14/) …
… based on "validation" test we add unit tests,
these tests do not depend on JDK version,
thus they cause failure of all builds …
these tests do not depend on JDK version,
thus they cause failure of all builds …
… then we implement desired behavior,
and builds are back to successful state …
and builds are back to successful state …
… only at this point we look at #CodeCoverage of individual unit tests to see whether we miss tests for some cases of new code or not, also note that this excludes high level "validation" tests …
… after that we create pull request with good description of why and what was changed,
it's time to update changelog with reference on pull request and ask for review …
it's time to update changelog with reference on pull request and ask for review …
… proper code review is never based only on changes visible in #GitHub,
it requires checkout into IDE and build by reviewer -
here is for example @marcandsweep using #AmazonWorkSpace to do proper code review while being on road in Toscana …
it requires checkout into IDE and build by reviewer -
here is for example @marcandsweep using #AmazonWorkSpace to do proper code review while being on road in Toscana …
… artifact of successful build of every branch is also available,
so that it can be tried by external contributors even before merge into master …
so that it can be tried by external contributors even before merge into master …
… PR is merged after successful review, and build of master aka "snapshot" version is published automatically - both on site (jacoco.org/jacoco/trunk/d…) and into #Maven snapshots repo (jacoco.org/jacoco/trunk/d…), so that it can be tried by early adopters even before release …
… that's how we do #TDD, #CodeReview and #ContinuousIntegration to keep master branch of #JaCoCo always releasable.
Hope you enjoyed this little story and learned something new today!
Hope you enjoyed this little story and learned something new today!
