Tag Archives: Continous Integration

Watch file changes and propagate errors with Gulp

Gulp fever infected me. Streaming model is very interesting and modern. After initial excitement, I started to experience first pitfalls. This is understandable for such young project. I am going to describe my problem with watching file changes and propagating errors.

Error in Gulp by default breaks the pipe, terminates the build/test and whole Gulp process with some error code. This is fine for CI process. But breaking the pipe stops file watch task also. This is big problem when developer wants to watch file changes and re-run particular tasks (e.g. tests).  You have to start watch task again after error occurs. This makes default watch task in Gulp pretty much useless. It is known and not the only problem of Gulp file watcher.

Fortunately Gulp 4 version if going to fix this. But I needed to come up with solution now. Google search points you to gulp-plumber. Idea behind it is to use gulp-plumber at the beginning of each pipe.

var plumber = require('gulp-plumber');
var coffee = require('gulp-coffee');


It prevents unpiping on error and forces the build process to continue regardless of error. Nice. Looks like problem with watch task solved.

I applied this approach on my pet project. It is simple node module that should store encrypted passwords into JSON file. But domain is not important for this blog post. When I checked in build process with gulp-plumber, I started to get false positives by drone.io CI server [EDIT: Build link doesn’t exist anymore].  Drone.io is using process error propagation, where each process returns error code. Non-zero value indicates error and zero means that process finished without error. gulp-plumber forces gulp process to continue and just writes errors to the console. Result is always zero error code from Gulp process.

So my goal is to use gulp-plumber to be able to continuously watch file changes and have fast feedback loop but also force Gulp process exit with non zero result when some error occurs.

First I declared variable to gather if error occurred.

var errorOccured = false;

Created handler for error recording.

var errorHandler = function () {
  console.log('Error occured... ');
  errorOccured = true;

Use gulp-plumber together with error handler for each Gulp pipe.

var transpilePipe = lazypipe()
  .pipe(plumber, {
    errorHandler: errorHandler
  .pipe(jshint.reporter, stylish)
  .pipe(jshint.reporter, 'fail')

//Compiles ES6 into ES5
gulp.task('build', function () {
  return gulp.src(paths.scripts)
      errorHandler: errorHandler

//Transpile to ES5 and runs mocha test
gulp.task('test', ['build'], function (cb) {
      errorHandler: errorHandler
    .on('finish', function () {
          errorHandler: errorHandler
        .on('end', cb);

This replaces gulp-plumber default error handler. It allows to record any error. (Example uses Lazypipe module. It can declare reusable pipe chunks. Lazypipe isn’t integrated with gulp-plumber, so it is needed also in sub-pipe.)

Next we need error checking Gulp task. It exits process with non-zero error code to indicate error state to Gulp process environment.

gulp.task('checkError', ['test'], function () {
  if (errorOccured) {
    console.log('Error occured, exitting build process... ');

Finally we call error checking task at the end of main Gulp task (right before submitting test coverage to coveralls.io in this case).

gulp.task('default', ['test', 'checkError', 'coveralls']);

Watch task is pretty standard, but doesn’t stop on error now.

gulp.task('watch', function () {
  var filesToWatch = paths.tests.concat(paths.scripts);
  gulp.watch(filesToWatch, ['test']);

And that’s it. Drone.io CI server properly highlights errors. I can also continuously watch file changes and automatically re-run tests. I agree that solution is little bit verbose, but I can live with that until Gulp 4 will be out.

Source code for this blog post can be found on Github.

Mastering Unit Testing Using Mockito and JUnit

Book Review: Mastering Unit Testing Using Mockito and JUnit

I was asked by Packt Publishing to write a review blog post about the new book Mastering Unit Testing Using Mockito and JUnit by Sujoy Acharya (released in Jun 2014). As I am passionate about all topics around testing or continuous development, I got exited. Nice side effect of this is that I could read this book for free ;). Book is 314 pages long. Divided into 10 chapters.


Summarizes why reader wants to test. Also why wants to have automated feedback loop. But there was very strong statement: “Greenfield projects always follow test-driven development to deliver maintainable and testable code.” Of course author probably wrote this before test first / test last battle. I am personally also TDD infected but there are definitely situations where it doesn’t make sense to do test first or test at all (e.g. prototyping). Also we should accept existence of test last approach. There are certainly very strong TDD opponents:

Chapter 1: JUnit4 – A Total recall

Guides reader how to create simple project in Eclipse. Leads him through JUnit features. It starts with basic fundamentals. Later in the chapter are described advanced parts of JUnit API. Some of these parts of the API should be used rarely or not at all (e.g. test methods ordering). This would be worth mentioning for beginners.  I wasn’t very excited because I am TestNG user. If you ever wrote some unit tests you probably would want to skip this chapter. Surprising for me was comparison of JUnit 4 @Before annotation with JUnit 3 setUp(). JUnit 4 is already 8 years old.

Chapter 2: Automating JUnit Tests

Elaborates about Continuous Integration. Also provides basic information about Gradle, Maven and Ant. Demonstrates very simple configurations of each build tool and how they run tests. Lastly touches simple Jenkins integration with each mentioned tool. Shame that configuration of examples across the book weren’t driven by any of this build tools.

Chapter 3:  Test Doubles

Brief explanation of theory behind faking dependencies of testing object. It also contains examples of each type (without usage of any testing framework so far).

Chapter 4: Progressive Mockito

Demonstrates Mockito syntax on examples. It goes through basic and also advanced Mockito features. At the end of the chapter is mentioned BDD (Behavioral driven development) style of testing. The only disturbing moment was manual inclusion of dependencies in example project configuration. Build tools were discussed in Chaper 2.

Chapter 5: Exploring Code Coverage

Author explains what code coverage means. After that shows some ways how to measure code coverage from Eclipse. I was surprised that he still accepts Cobertura as relevant tool, because Cobertura is dead project now. Last version was working only for Java 6. Java 6 was marked as “End of life” more that a year ago. That is why integration examples of Cobertura with Ant and Maven aren’t very useful. Examples how to integrate them with JaCoCo would be much more appropriate. I integrated JaCoCo with Maven in the past. It’s definitely doable.

EDIT: Cobertura is again under active development and is working for Java 7 now.

Chapter 6: Revealing Code Quality

This chapter shows three very useful Java static code analyzers

  • PMD
  • FindBugs
  • CheckStyle

Than it introduces SonarQube and its integration with mentioned build tools. It is very handy tool for monitoring technical depth on the project.

Chapter 7: Unit Testing the Web Tier

Some examples how you can test

  • Servlets
  • Spring MVC

But Spring MVC examples with Spring Test’s MockMvc library are missing. Examples in this chapter contain only plain Mockito + JUnit libraries. Readers should definitely take a look at MockMvc capabilities, because they are much more handier than explained approach.

Chapter 8: Playing with Data

This time author focuses on DAO layer. My personal opinion is that mocking Connetion or PreparedStatement in tests isn’t quite right. You can have test passing, but when you execute SQL statement against DB it can fail on some SQL error. I prefer to have integration tests for DAO layer.

Chapter 9: Solving Test Puzzles

Discusses constructs known as testability killers and some approaches how to solve them. I also discussed this topic in blog post series. I am glad that author doesn’t suggest usage of PowerMock. Rather takes the path of changing production code to enhance testability. Totally agree. Finally it shows example of TDD style of programming. Shame that this is the only example in the book where test is introduced before production code. So all other examples doesn’t follow TDD.

Chapter 10: Best Practices

This chapter dives into some common pitfalls reader can fall during writing the tests. Such advices are always good to keep in mind.


“Mastering Unit Testing Using Mockito and JUnit” book declares that was written for advanced to novice software testers and developers who use Mockito and JUnit framework. I would say that is only for beginners. It is mainly because book is covering wide range of topics around testing and its automation. There isn’t enough place dive deeply. Positive is covering nearly all aspects of professional unit testing. So it is very good start for developers that are willing to explore benefits of automated feedback loop. Author takes approach of hands on examples, so it is much better to read it next to the computer.