Inspired by Actual Events

Book Review: Learning JavaScriptMVC

2013-06-01T20:08:00.002-06:00

Packt Publishing invited me to review the recently published Learning JavaScriptMVC by Wojciech Bednarski. I describe my impressions of this book on JavaScriptMVC in this post. Before beginning my review, I'll quote the description of JavaScriptMVC from its web site: "A collection of the best practices and tools for building JavaScript applications" that is "built on top of jQuery." I reviewed the ebook (PDF) version of Learning JavaScriptMVC.

Learning JavaScriptMVC: Learn to build well-structured JavaScript web applications using JavaScriptMVC is a 100+ page book with six chapters. The Preface states that readers should "be familiar with JavaScript, browser APIs, jQuery, HTML5, and CSS." It also states that the book is intended "for anyone who is interested in developing small- and mid-size web applications with the JavaScriptMVC framework, which is based on the most popular JavaScript library – jQuery."

Chapter 1: Getting Started with JavaScriptMVC

The first chapter introduces "JavaScriptMVC (JMVC)" as "a JavaScript open source model-view-controller (MVC) framework" built "on top of the jQuery library." The chapter describes other aspects of JavaScript MVC such as historical details, basic objectives, license information, JavaScriptMVC architecture, the four major components of JavaScriptMVC (StealJS, FuncUnit, jQueryMX, and DocumentJS), and links for more information. A paragraph in this first chapter discusses future plans to rename (DoneJS (jQuery++) and CanJS) and make changes to the JavaScriptMVC framework and to some of its major components.

Chapter 1 includes details on three different approaches for installing JavaScriptMVC. One of the demonstrated approaches is via Vagrant and Oracle VM VirtualBox.

The first chapter also demonstrates using JavaScriptMVC with a sample application that can be compared to a similar sample to-do application built with other web frameworks at https://github.com/tastejs/todomvc/tree/gh-pages/architecture-examples. Several common web development techniques and tools are covered as part of this example: Google Chrome Inspector, jQueryMX, and Embedded JavaScript (EJS).

Chapter 2: DocumentJS

Chapter 2 covers DocumentJS, which it introduces as "a powerful, yet simple tool designed to easily create searchable documentation for any JavaScript codebase." I think it's worth re-emphasizing here that this is an independent tool that can be used with any JavaScript code base and is not limited to use on JavaScriptMVC applications.

Bednarski states in this second chapter that DocumentJS is quickly learned by anyone familiar with JSDoc, YUIDoc, YARD, or other Javadoc documentation tools. He also cites DocumentJS's support for Markdown as one of its advantages. This chapter adds documentation comments (look and feel a lot like Javadoc) to the code introduced for the sample application in Chapter 1 before covering how to generate documentation from these special source code comments.

Chapter 3: FuncUnit

The third chapter is devoted to FuncUnit, which it describes as "a functional testing framework with jQuery-like syntax" that "is built on top of the QUnit unit test framework." The chapter contrasts functional testing to unit testing and demonstrates using related tools Selenium, PhantomJS, and Envjs along with Maven and Jenkins.

Chapter 4: jQueryMX

The fourth chapter focuses on jQueryMX and describes jQueryMX as "a collection of jQuery libraries that provides functionality necessary to implement and organize large JavaScript applications." The chapter covers several jQueryMX plugins such as jQuery.Class (based on John Resig's Simple JavaScript Inheritance), jQuery.Model, and jQuery.View.

Chapter 5: StealJS

Chapter 5 covers StealJS and describes it as an "independent code manager and packaging tool." The chapter also states that "StealJS requires Java 1.6 or greater." The chapter demonstrates using StealJS to load files, to log, to clean/beautify code, and to concatenate and compress code. Related tools mentioned in this chapter include Google Closure and JSLint.

Chapter 6: Building the App

The final chapter's stated goal is "to show how to build a real-word application from concept through design, implementation, documentation, and testing." Along the way, the chapter mentions many process-related issues including use of Trello, Trac, JIRA, and Git. The example in the chapter also demonstrates using IndexedDB, PouchDB, and Sass.

Similarly to the first chapter, the last chapter is code-intensive as the entire application's code base is included in the chapter.

Positives

Conciseness - The author limits background details and opinions to sentences rather than the normal paragraphs or pages many authors devote to background and opinions.
Code Examples - The book is code-heavy with numerous pages devoted to code listings and to commands for running various tools.
Frame of Reference - This book's most useful feature may be that it provides an overall frame of reference for understanding what the JavaScriptMVC framework is. With the overall framework understood at a high level, the reader can go to other resources for additional or more in-depth details.
References - The book's conciseness (just over 100 pages total) leaves many details out and so it is helpful that it has numerous references to online resources with additional details.
Truth in Advertising - The book's preface stated that this book is intended for readers familiar with "JavaScript, browser APIs, jQuery, HTML5, and CSS." This is not overstated; the heavy use of code (especially JavaScript) means that the book is going to be much more useful to those already familiar with JavaScript and related technologies than those not familiar with those technologies. As the "Learning" part of the title implies, this book is an introductory book rather than a detailed reference book.

Negatives

Grammar and Sentence Structure - One of the advantages traditionally associated with books when compared to blogs is better spelling, grammar, and sentence structure in books. This is typically because books (and even articles) typically have much more editorial process than blog posts (the latter of which often have no editorial process). Unfortunately, much of this book felt like very little editing had occurred in the book publication process. There were numerous disjoint sentences and a couple cases where the chosen words did not seem to be used properly in the context in which they were used.
Good Online Documentation - This is really not a disadvantage of Learning JavaScriptMVC, but I thought it worth pointing out for those trying to decide whether to purchase the book. The online documentation for JavaScriptMVC seems fairly thorough and clear and might be sufficient for those wanting to learn and use JavaScriptMVC. In fact, the JavaScriptMVC documentation even includes its own To-Do example application. I often prefer having a printed or electronic copy of a book because they have some advantages, but this is also a matter of taste. It is important to reiterate that this book is an introductory book rather than a reference book.

Conclusion

I was happy to read Learning JavaScriptMVC and become more acquainted with JavaScriptMVC and how it fits in with other popular web development technologies and tools. This book seems best suited for developers who are about to use JavaScriptMVC without significant previous experience using that framework but with experience with JavaScript and other common web technologies. Learning JavaScriptMVC provides a different introductory perspective than the well-written online documentation and is filled with code examples demonstrating the concepts.

Java Happenings in May 2013

2013-05-31T07:00:00.001-06:00

This post very briefly summarizes some recent (within the past few weeks) developments in the world of Java.

Yet Another Java Versioning Scheme

Oracle has changed the Java version numbering schema again, this time in an effort "to avoid confusion caused by renumbering releases" because of the "recent increase of security releases" that have already led to skipped numbers and renumbered releases.

The Closure of java.blogs

Atlassian's java.blogs is currently closed, though it seems like this may not be permanent if there is sufficient interest in it being restored and updated. There is a form at the main site available for folks interested in it being restored to make that known.

Kicking the Tires of JDK 8

In Feedback Wanted, Java SE 8, Tori Wieldt provides links for downloading the latest released versions of Java SE 8 under development. She also provides links to the source code and to a list of Java Enhancement Proposals that have been incorporated into the latest JDK 8 releases. There are also links for reporting bugs found with a new release and for obtaining help if problems are encountered trying to use a new release.

JDK8 Javadoc Updates

Jonathan Gibbons's post javadoc TLC summarizes recent JDK8 tools fixes and the effect on Javadoc. I previously blogged on some changes in JDK8 Javadoc and its presentation of class methods.

Android, IntelliJ, and Gradle

Google I/O 2013 recently concluded and there were some big announcements in the Android space related to products that are well-known in the Java community. In particular, IntelliJ-based Android Studio is now offered (currently "early access preview") alongside more mature Eclipse-based Eclipse ADT plug-in and Gradle is now the main Android build system.

JAXconf

JAX Conference will be next week (June 4-5) in the Santa Clara Convention Center.

Java EE 7 Kick-off

The webcast Introducing Java EE 7 has been announced and will be broadcast live. Geertjan Wielenga has posted that NetBeans support for Java EE 7 will be featured in this webcast.

New JDK 7 and JDK 8 Early Access Releases

In Food For Tests: 7u40 Build b26 & 8 Build b91, Dalibor Topic writes of the new Early Access releases of JDK 7 Update 40 and JDK 8 Build b91. One thing of particular note is that the new JDK 8 build has "Nashorn replacing Rhino."

JDK 8's Calendar.Builder

2013-05-08T08:04:00.000-06:00

One of the defining characteristics of the brave new world of Java is the increasing prevalence of the builder pattern in the Java space. Groovy, which appears to be the most popular alternative language (to Java) on the JVM, is well-known for its heavy use of the Builder in both the core libraries and in Groovy-supported libraries and frameworks. Josh Bloch brought the pattern to the forefront of Java developer community mindset with coverage of the pattern in Item #2 of the second edition of his highly influential Effective Java. There have been several builders added to the JDK including the addition of Locale.Builder in J2SE 1.7. In this post, I briefly introduce Calendar.Builder coming to JDK 8.

Today, a Java developer typically populates an instance of the Calendar class by either calling one of the "set" methods that accepts a lengthy list of content for the instance or by calling individual "set" methods on the instance one after another. These two typical approaches for populating a Calendar instance are demonstrated in the next two code listings.

Populating Calendar with Single 'set' Method

/**
 * Demonstrate pre-JDK 8 method of instantiating Calendar instance using
 * "set" method for main fields.
 */
public static void demoCalendarWithSingleSet()
{
   final Calendar calendar =
      Calendar.getInstance(TimeZone.getTimeZone(timeZoneId),
         ENGLISH);
   calendar.set(2013, APRIL, 6, 15, 45, 22);
   out.println("Calendar via Constructor: " + stringifyCalendar(calendar));
}

Populating Calendar with Multiple Individual 'set' Methods

/**
 * Demonstrate pre-JDK 8 method of instantiating Calendar instance using
 * individual "set" calls for each pair of field names and values.
 */
public static void demoCalendarWithIndividualSets()
{
   final Calendar calendar =
      Calendar.getInstance(
         TimeZone.getTimeZone(timeZoneId),
         ENGLISH);
   calendar.set(YEAR, 2013);
   calendar.set(MONTH, APRIL);
   calendar.set(DATE, 6);
   calendar.set(HOUR, 3);
   calendar.set(MINUTE, 45);
   calendar.set(SECOND, 22);
   calendar.set(AM_PM, PM);
   out.println("Calendar via set methods: " + stringifyCalendar(calendar));
}

SIDE NOTE: In both of the examples above, I used another increasingly popular feature of modern Java: the static import. The constants such as ENGLISH, YEAR, and SECOND are actually statically imported from classes such as Locale and Calendar. As I have previously written, static imports seem to be increasingly popular with Java developers, especially in light of the trend toward fluent interfaces.

The two "traditional" approaches shown above show different ways to populate the Calendar instance. One extreme is to set each individual field separately while the other is to set all the significant fields with a single "set" method. There are advantages to each approach. The single "set" method has fewer states of an "unfinished" object than the multiple-set approach, but the multiple-set approach is more readable because the name of the value being set is clear based on the first parameter to each "set" method. The single-set approach is a little unwieldy because it takes six integers that can be easily mixed up in order passed because there is no obvious way to differentiate which integer is which other than the implicit order.

Calendar.Builder leverages on the advertised benefits of the Builder as described by Bloch: removes the existence of "inconsistent states partway through [an object's] construction." This is demonstrated in the next code listing.

Calendar.Builder Allows Single-Statement Instantiation with Readable Settings

   /**
    * Demonstrate using JDK 8's Calendar.Builder to instantiate an instance of
    * Calendar using the set methods to set each field individually based on
    * field name and value.
    */
   public static void demoCalendarWithCalendarBuilderSetFields()
   {
      final Calendar calendar =
         new Calendar.Builder()
            .set(YEAR, 2013)
            .set(MONTH, APRIL)
            .set(DATE, 6)
            .set(HOUR, 15)
            .set(MINUTE, 45)
            .set(SECOND, 22)
            .setTimeZone(TimeZone.getTimeZone(timeZoneId))
            .setLocale(ENGLISH)
            .build();
      out.println(
           "Calendar via Calendar.Builder 'set' Fields: "
         + stringifyCalendar(calendar));
   }

In the above code listing, the Calendar instance is created AND populated in one statement, removing the need to risk an object being in an inconsistent state across multiple statements. This example retains the readability of the traditional individual "set" methods approach [set(int, int)] with the added safety of having the object populated fully immediately at instantiation.

For developers who want to provide fewer individual "set" methods, another opportunity with Calendar.Builder is to use the setDate(int, int, int) and setTimeOfDay(int, int, int) methods as demonstrated in the next code listing.

Calendar.Builder Setting Date and Time as Two Calls

/**
 * Demonstrate using JDK 8's Calendar.Builder to instantiate an instance of
 * Calendar using the "setDate" and "setTimeOfDay" builder methods.
 */
public static void demoCalendarWithCalendarBuilderSetDaySetTime()
{
   final Calendar calendar =
      new Calendar.Builder()
         .setDate(2013, APRIL, 6)
         .setTimeOfDay(15, 45, 22)
         .setTimeZone(TimeZone.getTimeZone(timeZoneId))
         .setLocale(ENGLISH).build();
   out.println(
        "Calendar via Calendar.Builder setDate/setTimeOfDay: "
      + stringifyCalendar(calendar));
}

There are fewer characters and lines to type with this approach, but it partially reintroduces the disadvantage of being more likely to have an integer parameter inadvertently switched as each of the two methods takes three integers (or an overloaded version of setTimeOfDay() will take a fourth integer representing milliseconds).

For developers wanting the ultimate flexibility in specifying Calendar parameters during its instantiation, Calendar.Builder provides the method setFields(int ...) that takes an arbitrary length of pairs of integers with the first integer of the pair representing the field to be set and the second integer of the pair representing the value for that field. This method is used in the next code listing.

Specifying Calendar Fields via Calendar.Builder's setFields Method

   /**
    * Demonstrate using JDK 8's Calendar.Builder to instantiate an instance of
    * Calendar using the setFields method that allows providing of Calendar
    * fields as key/value pairs.
    */
   public static void demoCalendarWithCalendarBuilderSetPairs()
   {
      final Calendar calendar =
         new Calendar.Builder()
            .setFields(YEAR, 2013, MONTH, APRIL, DATE, 6, HOUR, 15, MINUTE, 45, SECOND, 22)
            .setTimeZone(TimeZone.getTimeZone("timeZoneId"))
            .setLocale(ENGLISH)
            .build();
      out.println(
           "Calendar via Calendar.Builder setPairs: "
         + stringifyCalendar(calendar));
   }

This setFields(int ...) method brings greater risk of mangling the order of integers used for instantiation of the new instance of Calendar, but using the statically imported Calendar constants does improve readability and reduces the likelihood of mixing the integers incorrectly. If an odd number of integers is provided (meaning that there is an incomplete pair), an IllegalArgumentException is thrown.

Although Calendar.Builder provides some convenience in instantiating and populating an instance of Calendar, anyone fortunate enough to adopt JDK 8 will have access to the new date/time API and so the question might be asked, "Why use Calendar.Builder?" Perhaps the best answer is that there are millions of lines of existing code, libraries, and frameworks out there using and expecting Calendar instances, so it will probably be a long time before the need for Calendar is completely gone (if ever). Fortunately, Calandar.Builder makes it easy to covert an instance of Instant (part of the new Java data/time API) into a Calendar via CalendarBulder.setInstant(long). This is demonstrated in the next code listing.

Converting Instant to Calendar with Calendar.Builder

   /**
    * Demonstrate using JDK 8's Calendar.Builder to instantiate an instance of
    * Calendar based on "now" Instant.
    */
   public static void demoCalendarWithCalendarBuilderInstant()
   {
      final Calendar calendar =
         new Calendar.Builder().setInstant(Instant.now().toEpochMilli())
            .setTimeZone(TimeZone.getTimeZone(timeZoneId))
            .setLocale(ENGLISH)
            .build();
      out.println("Calendar via Calendar.Builder and Instant: " + stringifyCalendar(calendar));
   }

Note that an overloaded version of the setInstant method accepts a Date for instantiating a Calendar. In both cases, whether instantiated with setInstant(long) or setInstant(Date), no other "set" method on Calender.Builder should be called to avoid an IllegalStateException.

It is easy to go the other direction (getting an Instant from a Calendar) using Calendar.toInstant(). Other methods introduced to Calendar with JDK 1.8 are related to providing the current instance's calendar type (as a String) or the set of available calendar types (Set of Strings). When I run Calendar.getAvailableCalendarTypes() on my system, I see these three Strings: "gregory", "japanese", and "buddhist" (the same three calendars documented in Supported Calendars)

Conclusion

Like many Java developers, I'm looking forward to an improved Java data/time API that is built into the standard Java Development Kit. However, I also realize that, especially in large code bases and when using libraries and frameworks expecting Calendar or Date, that I won't be free of Calendar and Date for some time. The introduction of Calendar.Builder in JDK 8 eases that burden a bit.

Interesting Java Blog Posts in Mid-April 2013

2013-04-26T08:37:00.000-06:00

There have been numerous Java-related blog posts in recent days and I reference and summarize four of them here.

Creating a Memory Leak

In the "rather evil post" How to Create a Memory Leak, Ivo Mägi describes and provides code examples of two commons leaks. The first leak covered is related to objects lacking the hashCode()/equals(Object) implementations to be used properly in collections needing them to be correct. The second covered leak is related to the change of handling for String internals in Java 7 Update 6. The second problem is a reminder of the subtle and difficult to diagnose issues that can occur when even minor differences exist between versions of Java used in different environments.

StringBuffer Was Never a Good Idea

Peter Lawrey's blog post Why a synchronized StringBuffer was never a good idea articulates something I've found to be the case: most uses of building up strings do not need to be thread safe. Even when thread safety is needed, Lawrey points out why StringBuffer often is not sufficient.

9 Fallacies of Java Performance

Ben Evans looks at 9 Fallacies of Java Performance including the outdated mantra "Java is slow" and problems with using microbenchmarks to make performance decisions. He points out that "Java performance-tuning intuition is often misleading" and that "we require empirical data and tools to help us visualize and understand the platform's behavior."

Infamous Java Bugs and Pitfalls

Murat Yener has collected some Java-related "bugs and pitfalls" in his post Infamous Java Bugs and Pitfalls such as autoboxing issues and BigDecimal quirks.

Conclusion

The four blog posts on Java cited above have been recently posted and provide good reminders and potentially new information on things to be cognizant of when developing with Java.

More Reasons to Update to Java 7

2013-04-22T08:50:00.000-06:00

In Java SE 7 Update 21 Release and more, Tori Wieldt pointed out that "Oracle has released three updates to Java" this past week: Java 6 Update 45, Java 7 Update 21, and Java SE Embedded 7 Update 21. This The Java Source blog post briefly focuses on "new security features in this release" (more than just security fixes): "new Server JRE package" (tools used commonly for server "without the Java plug-in, auto-update or installer found in the regular JRE package"), removal of low and custom settings from Java Control Panel, and changes to Security Dialogs. Markus Eisele has posted additional details on the new security features in Java 7 Update 21 Security Improvements in Detail.

Whether it be security fixes or security features, the attention paid to security in Java SE 6 and Java SE 7 has come at a price: it looks like Java 8 is likely to be delayed again (this time pushing General Availability to First Quarter 2014). In the blog post Java 8: Secure the train, Mark Reinhold writes, "Maintaining the security of the Java Platform always takes priority over developing new features, and so these efforts have inevitably taken engineers away from working on Java 8. ... As a consequence of this renewed focus on security the Java 8 schedule, with a GA release in early September, is no longer achievable." For people waiting to upgrade from Java 6 to skip to Java 8, this delay of Java 8 is another reason to consider upgrading to Java 7 now.

Although Oracle has been warning of the end of free availability of Java 6 updates since the beginning of the year and extended Public Updates multiple times, Henrik Stahl's post Oracle JDK 7u21 released with new security features states that "we are not planning any more public JDK 6 updates" (past Java 6 Update 45). Users of Java 6 are encouraged to migrate to Java 7 to continue receiving public updates. In his Question-and-Answer formatted post, Stahl also covers alternatives such as access to newer Java 6 releases via the appropriate support license ("Oracle middleware or applications customer") or via separately purchased Java SE support.

Besides access to future public releases of Java SE, there are other reasons to upgrade to Java 7. Some of these are enumerated in 7 reasons to upgrade to Java 7 and the "Features of Java 7" section of "Why should I upgrade to Java 7?"

JDK 8 Javadoc Tweaked For Methods Listings

2013-04-16T08:03:00.000-06:00

Since its beginning, Javadoc output has been largely static HTML with navigation links and simple stylesheet styling of its appearance. Java SE 7 saw the first significant change in Javadoc output default appearance in a long time and now it looks like JDK 8 will introduce a new twist on generated Javadoc output. In this post, I look briefly at the more dynamic filtering of methods in Javadoc output by type of method that appears to be available with JDK 8's javadoc tool.

The following two screen snapshots compare the JDK 7 and JDK 8 versions of default Javadoc output for the Calendar class (chosen for its variety of method types).

Although the Javadoc output for JDK 8 has the same overall styles (including orange "tabs" for "Constructors", "Fields", "Methods" and so forth) as Java 7 Javadoc documentation, the methods in the JDK 8 generated documentation have multiple orange tabs above the listing of methods that allow the reader to click on the appropriate tab to see the appropriate subset of methods. The names of the tabs are about as self-explanatory as you could want with names like "All Methods" (all methods on the class), "Static Methods" (class-level methods), "Instance Methods" (object-level methods), "Abstract Methods" (methods without implementation), and "Concrete Methods" (implemented methods).

The next series of screen snapshots demonstrate how clicking on any of these tabs invokes embedded JavaScript code that calls appropriate functions in the script.js file that exists at the root level of the generated Javadoc directory structure.

This is a minor, but still somewhat handy, feature of Javadoc in JDK 8. I have often looked through methods of Javadoc for a class with mixed method types for methods that fit one particular type. Now, rather than needing to scan for keywords such as "static" or "abstract" or for the absence of those same words, I can simply use these "tabs" to filter the types of methods I want to see for a given class.

Browsing the COS Naming Service Namespace with Groovy

2013-04-15T07:26:00.000-06:00

There was a time when CORBA was all the rage and was as trendy and popular as any favored technology that has come along since. Although CORBA does not get the attention in blogs and other online media that it would have in those days or that other technologies get today, it still underlies several of the technologies that many of us use. In this post, I look at using Groovy to browse the objects in a hierarchical namespace associated with the CORBA Common Object Services (COS) Naming Service that is provided by Java IDL (which also includes command line tools) and supports GlassFish's EJBs.

The Oracle Java SE Documentation contains a highly useful page called Naming Service that provides Java source code with explanations for adding objects to the namespace, resolving objects from the namespace, and browsing the namespace. In this post, I convert the Java code providing for the third example (browsing the namespace) to Groovy for a script that is easy to use to check objects in the namespace. That script is shown next.

browseNamingService.groovy

#!/usr/bin/env groovy
//
// browseNamingService.groovy <hostname> <port>
//
// Adapted from Example #3 at
// http://docs.oracle.com/javase/7/docs/technotes/guides/idl/jidlNaming.html#example3

if (args.length < 2)
{
   println "\n\nUsage: browseNamingService.groovy <hostname> <port>\n\n"
   System.exit(-1)
}

import java.util.Properties
import org.omg.CORBA.*
import org.omg.CosNaming.*

def properties = new Properties()
properties.put("org.omg.CORBA.ORBInitialPort", args[1])
properties.put("org.omg.CORBA.ORBInitialHost", args[0])
def orb = ORB.init(args, properties)

def namingContext = NamingContextExtHelper.narrow(orb.resolve_initial_references("NameService"))

def bindingList = new BindingListHolder()
def bindingListIterator = new BindingIteratorHolder()
namingContext.list(1000, bindingList, bindingListIterator)
def bindings = bindingList.value

bindings.each
{ binding ->
   def lastIndex = binding.binding_name.length-1;

   // BindingType of ncontext indicates this is a naming context; only other
   // BindingType is nobject.
   if (binding.binding_type == BindingType.ncontext)
   {
      println "Context: ${binding.binding_name[lastIndex].id}"
   }
   else
   {
      println "Object: ${binding.binding_name[lastIndex].id}"
   }
}

For details on what the script above is doing, see the discussion surrounding the Java code from which this was adapted. The script makes it easy to provide a hostname and port and find the objects referenced in the namespace at that host and port. This is shown in the GlassFish (port 3700) in the next screen snapshot.

In this case, I happened to know that my GlassFish installation used the default port of 3700 for this CORBA COS Naming Service, but I also could have found that port in the GlassFish web-based Admin GUI as shown in the next screen snapshot.

When you don't know the appropriate port and the product whose port you are looking for the Naming Service on doesn't indicate the appropriate port, you can use tools to find potential ports such as netstat, lsof, and TCPView for Windows. Any of these ports run through the above script without a stack trace and that return names are posts on which a CORBA COS Naming Service is hosted.

Book Review: Effective Unit Testing: A Guide for Java Developers

2013-04-12T20:29:00.003-06:00

In the Preface for Effective Unit Testing: A Guide for Java Developers, author Lasse Koskela states that although the impetus for Effective Unit Testing was to "write a Java edition of Roy Osherove's book, The Art of Testing with Examples in .NET," Effective Unit Testing ended up "having very little in common with Roy's book." Koskela further explains in the Preface that "this book is for the Java programmer," but adds that "writing good tests is a language-agnostic problem" and he recommends his book even for developers using languages other than Java.

Koskela does a nice job in the "Preface" of succinctly summarizing what the book is and isn't when he says, "I didn't want to give you a tutorial on JUnit or my favorite mock object library" and "I've tried to minimize the amount of technology-specific advice." This is important to note because Effective Unit Testing is not the book you'll want if you're looking for a book covering intricate details of JUnit, TestNG, Mockito, EasyMock, Hamcrest or other commonly used Java unit testing frameworks and tools. Instead, the focus of Effective Unit Testing: A Guide for Java Developers is on more general concepts of unit testing in general (and in Java in particular) that might be implemented with any variety of different tools. That being stated, Koskela doesn't ignore these tools completely and does sprinkle JUnit code throughout the book along with code samples based on other unit testing tools such as JMock, Mockito, and Hamcrest.

Chapter 1: The Promise of Good Tests

In Chapter 1 of Effective Unit Testing, Koskela mixes brief historical testing anecdotes with basic introductory material and often-cited reasons on why unit tests and automated tests are important (identifying bugs, improving design, avoiding scope creep, and learning from the test-writing experience). Koskela talks about why units tests are more effective when used for design in addition to being used for quality assurance.

The "Factors of Productivity" section of Chapter 1 is useful for understanding certain measures by which one might determine whether unit tests are "effective." These include execution speed (performance), readability, reliability, and trustworthiness. Achieving these characteristics of effective unit tests is the focus of the book. A couple concluding sections of the first chapter focus on using tests for design and employing behavior-driven development (BDD).

Among other introductory details, he articulates why "100% code coverage isn't the goal." Several well-known testing-related terms ["test-infected", "test-driven development" (TDD), and "accidental complexity"] are also introduced in this chapter along with references for additional details. In this first chapter, the author also introduces his "The Law of Two Plateaus" to differentiate between using unit tests solely for quality assurance versus using them for design in addition to quality assurance.

Chapter 1 is mostly introductory and probably doesn't hold a lot of new insights for someone who has worked with Java extensively and/or has written unit tests extensively. However, it does manage in 12 pages to meet the author's goal for it and the other two chapters (Chapter 2 and Chapter 3) of Part 1 of providing a "shared context" for the remainder of the book.

Chapter 2: In Search of Good

Chapter 2 delves deeper into the question of "What makes a test 'good'?" Koskela is quick to point out that there is some subjectiveness to this ("some of the quality of test code is in the eye of the beholder" as is the case for any code) and that different contexts can affect whether a particular unit test is good or not.

Koskela discusses in this chapter how virtues of regular source code are often valued virtues of test code. For example, he discusses that readable test code is maintainable test code and that appropriate structure plays a big role in making tests understandable. Koskela devotes a section of Chapter 2 to a smaller but significant issue I've seen repeatedly in writing and maintaining my own and others' unit tests: unit test methods that advertise testing something they don't really test (perhaps because they are named poorly) can be very costly. I like what Koskela titles that section, "It's not good if it's testing the wrong things." This sounds obvious, but there is deep truth to that simple statement.

Another section of the second chapter focuses on the principle that, for good tests, "independent tests run easily in solitude." Koskela provides a list of dependencies (such as "randomness" and "persistence") that to him are code smells indicating that something might be wrong with the unit test code. I like his "litmus test for a project's test infrastructure" to satisfy the following scenario: "Can I check out a fresh copy from version control to a brand new computer I just unboxed, run a single command, lean back, and watch a full suite of automated tests run and pass?" This section does a nice job of covering why it's important that tests are independent and do not rely on being called in a certain order. In addition to pointing out some unit test dependency smells in this section, Kosekla also provides some specific approaches that might be taken to address these.

One of the sections of the second chapter of Effective Unit Testing looks at why testing the wrong thing or even testing nothing at all ("happy tests") are problematic. There is coverage of why tests "need to be repeatable" along with references to Java-specific examples of tests that introduce things outside of the testing developer's control into the tests.

The last section of Chapter 2 (not counting the "Summary") introduces test doubles, the subject of Chapter 3. Koskela defines test doubles as "an umbrella term for ... stubs, fakes, or mocks." He adds that "test doubles" are "objects that you substitute for the real implementation for testing purposes." Koskela groups test doubles with testing frameworks and build tools as his "top three tools of the trade for software developers writing automated tests."

Chapter 3: Test Doubles

The third chapter is the concluding chapter and my favorite chapter of Part 1 ("Foundations"). The chapter is devoted to coverage of "test doubles", a term and concept introduced in Gerard Meszaros's xUnit Test Patterns: Refactoring Test Code. Koskela outlines five reasons developers might use test doubles, including "the most fundamental of the reasons for employing a test double - to isolate the code you want to test from its surroundings." After listing these five reasons for use of test doubles, Koskela describes each of these motivating reasons in greater detail. He then describes each of the types of test doubles and compares their strengths and weaknesses. Koskela's section "Guidelines for Using Test Doubles" introduces his "logic and heuristics" for "picking the [test double] option that results in the most readable test". These include five considerations plus the simplifying rule: "stub queries; mock actions" (attributed to J.B. Rainsberger, author of JUnit Recipes).

The third chapter of Effective Unit Testing also touches on organizing unit tests with the Arrange-Act-Assert convention and likens this to behavior-driven development's Given-When-Then vocabulary. This chapter also demonstrates principles of the chapter with brief forays into JMock and Mockito code examples and a reference to J.B. Rainsberger's blog post JMock v. Mockito, but Not to the Death.

Chapter 4: Readability

The fourth chapter of Effective Unit Testing is the first chapter of Part 2 ("Catalog"). As with all three chapters in Part 2, Chapter 4 looks at "test smells" that might indicate tests that are less effective than they could be. In this chapter's case, the test smells are those most closely associated with problems related to readability of unit tests.

Koskela starts Chapter 4 by articulating the difference between reading test code and running test code: "Reading the tests ... should provide the programmer with an understanding of what the code should do. Running those tests should tell the programmer what the code actually does."

The test smells that Koskela associates most closely with the "readability" portion of his Test Smells Catalog are:

Primitive Assertions
- Assertion that "uses more primitive elements than the behavior it's checking"
- Analogous to the primitive obsession code smell
Bitwise Assertions
- Special case of Primitive Assertions that uses bitwise operators for "optimized test assertions" at the cost of readability and understandability
Hyperassertions
- Assertion that that "becomes brittle and hides its intent under its overwhelming breadth and depth"
Incidental Details
- Incidental details make it difficult to identify the "intent, purpose, and meaning" of a unit test
Split Personality
- Unit test "embodies multiple tests" rather than obeying unit test mantra "A test should only check one thing and check it well"
Split Logic
- Test code scattered over multiple files
Magic Numbers
- Using numeric and String literals rather than using constants and variables with readable names
Setup Sermon
- Too much code (often refactored from tests suffering incidental details smell) in the setup method
Overprotective Tests
- Application of unnecessary/redundant guard or test assertions when condition would fail anyway

In each test smell case, Koskela provides examples of these test smells along with one or more ways (description and code examples) of addressing the smells.

Hamcrest is introduced in Chapter 4 as a partial solution to addressing test smells. There is also a unit test example that is built for testing JRuby source code.

In the fourth chapter, Koskela provides some memorable quotes. He articulates an opinion that I've long held regarding unit test code: "When weighing alternatives to expressing intent in test code, you should keep in mind that the nature and purpose of tests puts a higher value on readability and clarity than, say, code duplication or performance." He also writes, "A test that has never failed is of little value - it's probably not testing anything. On the other end of the spectrum, a test that always fails is a nuisance." Koskela also explains that "A test should have only one reason to fail" and explains that this is related to the Single Responsibility Principle.

Chapter 5: Maintainability

Chapter 5 continues the coverage of test smells, but moves from the focus of Chapter 4 on "readability" to focus instead of "maintainability." As he did in Chapter 4, Koskela enumerates several test smells most closely associated with test maintainability and uses code examples to demonstrate these smells and how to address these smells.

Chapter 5 focuses on the following "maintainability" test smells:

Duplication
- Needless repetition that increases places where same change must be made and increases risk of not changing all necessary code
- Duplication can be structural or semantic or both
Conditional Logic
- "Conditional execution structures such as if, else, for, while, and switch" reduce the ability to use tests to "understand what the code does and what it should do"
Flaky Test
- Tests that "fail intermittently," typically due to multithreading or race conditions
Crippling File Path
- Absolute paths, especially hard-coded absolute paths, prevent unit tests from being run on others' machines
Persistent Temp Files
- Files that are generated by unit tests may be less temporary than one realizes and interfere with later tests
Sleeping Snail
- Use of Thread.sleep(long) calls in unit test methods
Pixel Perfection
- Specialized version of Primitive Assertion and Magic Numbers test smells applied to exactly matching graphic representations in unit tests
Parameterized Mess
- Result of overusing and abusing parameterized tests
Lack of Cohesion in Methods
- "Test methods in a test class are only interested in some of the fixture's objects"

As he did for the test smells covered in Chapter 5, Koskela provides code-based examples of each test smell discussed in Chapter 5 along with code-based examples of how to address each of the code smells.

Chapter 6: Trustworthiness

Chapter 6 finishes off Part 2 and the Catalog of Test Smells. Chapter 6's focus is on test smells closely associated with the degree of reliability and trustworthiness of tests. The test smells covered in this chapter are:

Commented-out Tests
- Commenting out tests' implementations so they appear to pass when they really aren't run at all ("poor man's version control")
- Removing @Test annotation from JUnit 4-based unit test method has same negative effect
- Use of @Ignore (JUnit) is similar
Misleading Comments
- Confuse what the tests are really testing (a famous code smell as well as test smell)
Never-failing Tests
- "A test that can never fail is probably worse than not having that test ... Tests are supposed to fail when they should."
Shallow Promises
- A "tests that does much less than what it says it does - or does nothing at all"
- One type of "shallow promise" test smell (commenting out the body of the test method but not its signature and @Test annotation) misleads people to think test of something significant passed
- Lack of assertions in a test method is another specific example of this test smell
- Method name implying different functionality tested than what is actually tested is third example
Lowered Expectations
- "Tests that are overly robust - they don't fail when they should," usually because "assertions are too vague"
Platform Prejudice
- "Failure to treat all platforms equal"
Conditional Tests
- "... conditional tests in our tests ... [are] bad in general"
- "All branches in a test method should have a chance to fail"

Koskela uses code samples to illustrate the Chapter 6 code smells and what unit tests look like once the test smells are addressed with his recommendations. Chapter 6 wraps up Part 2 on the Catalog of Test Smells.

Chapter 7: Testable Design

Proponents of Test-Driven Development and even many proponents of any type of unit testing argue that unit testing is as much about design as it is about testing. As mentioned earlier, Koskela wrote about the Law of Two Plateaus in Chapter 1 and explained that significantly more benefit can be obtained from unit tests when they are used for more than quality assurance and are used in the design process. Chapter 7 returns to this idea and focuses on what it means to be a "testable design." Koskela defines testable design as "[making] it easy to instantiate classes, substitute implementations, simulate different scenarios, and invoke particular execution paths from our test code."

Koskela describes several design principles that lead to testable design: modular design, SOLID principles [Single Responsibility Principle, Open Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, Dependency Inversion Principle]. Koskela discusses these principles of object-oriented design and how software that adheres to them is inherently more testable./p>

Koskela articulates an advantage of writing unit tests early that I've definitely observed: "The act of writing tests before the implementation they call for is essentially a way to ensure that you're taking the client's view on the code you're shaping."

Section 7.2 of Effective Unit Testing looks at several "testability issues" and then Section 7.3 addresses these testability issues with "guidelines for testable design." It is worth nothing here that Section 7.2 and Section 7.3 (and really the entire book) make the assumption that these Java unit tests are run without use of reflection or bytecode manipulation. Using these tools, such as provided by PowerMock, would be one way to address some of these issues, but do add complexity to the unit tests.

I expected Section 7.3 to be the most controversial part of the book for me. It's not that I expected the book to be controversial; rather, it is the topic that is controversial. It has always bothered me when I have to change my production code design for no other reason than to accommodate a unit test. In practical terms, I often cave in and do this because the negative effect on my production code design is less significant than the benefit of unit testing, but I still don't have to like doing it.

In Section 7.3, Koskela describes some of the commonly-held assertions about testable Java code, including avoiding complex private methods, avoiding final methods, avoiding static methods, avoiding logic in constructors, avoiding the singleton, favoring composition over inheritance, and wrapping external libraries. I started reading this section expecting to think, "Yeah, but ...." Instead, I found myself largely agreeing with Koskela's arguments based on my own experience. His pragmatic attitude made his assertions in this section agreeable and realistic. For example, he advises to avoid "complex private methods" rather than simply stating avoid private methods altogether. I've always liked when good design principles are also good for testability and Koskela manages to couch most of these "testable design principles" as such.

Chapter 8: Writing Tests in Other JVM Languages

I'm a big fan of Groovy (127 blog posts to date labeled Groovy) and am increasingly interested in Scala, so I looked forward to reading Chapter 8 on unit testing with alternative JVM languages. Koskela provides a brief history of languages other than Java on the JVM and covers some benefits common to these alternative languages.

Although Koskela mentions Scala, Clojure, JRuby, Jython and even non-JVM Ruby in Chapter 8, the lion's share of the chapter is on testing with Groovy and Groovy-based tools. In particular, the chapter covers using Groovy for testing directly as well as using Groovy-based BDD testing frameworks easyb and Spock Framework.

Chapter 9: Speeding Up Test Execution

There are numerous factors that can demotivate Java developers when it comes to unit testing. Perhaps none is more significant than slowly executing tests. If running the tests starts to take too long, the developer might lose interest in running them as often. As they are used (run) less, the developer may start to question the investment of time and energy in writing and maintaining them. Also, as they are run less, it becomes increasingly likely that problems the test would flag will go on longer before being caught.

Koskela covers ideas for improving unit test execution performance in the ninth and final chapter of Effective Unit Testing. He begins by looking at why it is important to have fast tests (both builds and test execution) and follows that with looking at strategies to make the builds and execution of tests quicker.

Chapter 9 includes brief coverage of using Ant and Maven for building unit tests and how to profile build performance with both of those tools. Until reading this chapter I was not aware of Ant's built-in ProfileLogger (since 1.8) or Ant-Contrib. This chapter also demonstrates how to use Koskela's maven-build-utils extension. Ant's JUnitReport task and Maven's maven-surefire-plugin are also demonstrated in this chapter.

Besides covering build and execution profiling tools and how to use them to identify the tests that really need to have their performance addressed, Koskela also provides several tactical approaches one can use to improve test execution efficiency. These are solid ideas that I don't consider premature optimization because they are, for the most part, simply good ideas in general that potentially improve performance without sacrificing readability or maintainability of the tests. Another thing I like about these tactical approaches is that many of them have been covered in a slightly different perspective earlier in the book. This ending chapter now brings those previously discussed principles back into the discussion for improving test performance while at the same time addressing test smells.

All of Koskela's tactical suggestions for better performing unit tests make sense to me, but I particularly liked his coverage on database access in unit tests because I so often see this violated at extreme cost. I like his emphasized statement: "friends don't let friends use a database in their unit tests." He explains (and I agree) that integration tests are more appropriate for testing of actual database access.

There is a table in Chapter 9 (Table 9-1) that summarizes approaches one might take to address the two primary external constraints on unit test execution performance (CPU and I/O). Koskela then moves onto detailing how to implement some of these mitigation approaches. Several tools are covered in this chapter including some Linux tools, but two of the most interesting and new to me were Koskela's descriptions of how to use Amazon Web Services and GridGain to improve unit test building performance.

Appendices

Appendix A is a 7-page "JUnit Primer" that covers basics of JUnit with focus on assertions and use of Hamcrest matchers. Appendix B is a little over 6 pages on "Extending JUnit" with focus on runners and rules.

Test Smells

For me, the heart of Effective Unit Testing is Part 2 (plus Chapter 7 and Chapter 9 of Part 3 which I highlight next) that catalogs the test smells. This Part 2 is great at outlining issues I've run into with unit tests that can make unit testing more painful than it needs to be. It is also easy to see that there are trade-offs between the test smells such that the very approach that alleviates one test smell may increase risk of introducing another test smell. One example is the trade-off between duplication and readability in unit tests. The author talks about many of these trade-offs and provides rough guidelines of how to decide which way to lean without going too far in either direction. In the case of unit test readability at the cost of some duplication, I like stucampbell's take on this: "I'm more likely to refactor duplicated code for setting up state. But less likely to refactor the part of the test that actually exercises the code."

Testable Design and JUnit Performance

Like all three chapters in Part 2 on test smells, two of the chapters in Part 3 (Chapter 7 on testable design and Chapter 9 on unit test performance) are also chapters that I plan to re-read in the future. There is a lot packed into these chapters that directly address common unit testing issues as well as sparking ideas about other approaches that could be used to improve unit testing.

The Audience

As one would expect from a book with the title Effective Unit Testing, this book does indeed provide guidance on what separates effective unit tests from less effective unit tests. Not only does it cover practices one should use and should avoid, but it introduces terminology and cites well-known resources in the unit testing literature. As such, it is not only an appropriate book for someone with basic familiarity with unit testing who wants to improve their unit tests, but is also highly relevant to those new to unit testing in general and unit testing in Java in particular who want an overview of unit testing in Java. This book doesn't have enough details to be the only source of information for someone new to unit testing in Java, but does give the overall high-level view that can provide context for reading literature more specifically focused on frameworks and other unit testing tools.

Part 1 will be least interesting to those with significant experience with unit testing, but will be of high value to those who are new to unit testing or non-coding managers and leads who want an overview of why unit testing is important and what kinds of high-level things can make unit tests less effective or more effective. Although Part 1 was the least interesting to me, I still felt it was well-written and met the author's stated goal of providing a common context for the remainder of the book.

Part 2 and Part 3 are more technically detailed than Part 1. I like the overall descriptions of test smells and approaches to scrub these test smells in Part 2. I also really like the coverage in Part 3 of ideas for improving test build and execution performance and related to how to design code that is more testable.

What This Book is Not

As I have stated in this post and as the author reminds the reader of Effective Unit Testing, this book is not the book one should use to learn details of JUnit or other testing framework. There is just enough coverage of these to illustrate more general points, but the focus is on unit testing principles rather than on unit testing implementation libraries and frameworks. Although someone new to unit testing Java applications could find this book useful (particularly Part 1), some knowledge of JUnit would be beneficial (particularly for Part 2 and Part 3).

The Book Advantage

I have found that different mediums have different advantages when it comes to conveying information and learning. Although many of the principles found in this book are available online in various forms, the strength of the book is the author's organization and articulation of the ideas in a single coherent source. I think the book is well worth its price when I think of the time it would take to collect and organize these ideas from online sources. Furthermore, the author provides examples from his own and friends' experiences to add a "real life" feeling to it all. A well-written book's advantage over blog posts, forum threads, and the like is the ability to cohesively and coherently cover a topic with breadth and depth. This book does just that for the topic of unit testing in Java. To me this book may not offer a lot of new high-level concepts (although it does offer some new to me low-level details), but it articulates well the ideas and practices that seem to be emerging from collective experience writing unit tests for Java-based applications.

Breadth of References

Another thing I liked about Effective Unit Testing is the abundance of reference to sources with additional details on the ideas, concepts, tools, and frameworks referenced in the book. Some might argue that a downside of the book is that most of the concepts are not new. I actually argue the opposite: because these are practices for effective unit tests, one would expect them to be based on what more than one person has found to be effective through hard experience. When I am reading a book on "effective" anything, I'm not looking for something that is simply "new" or "different"; I am looking for things I should generally do and generally not do and why. By referencing others' work in unit testing as well as describing his own efforts in this area, Koskela increases the credibility of his book. I also liked the mixing of alternative languages, frameworks, and operating systems in the examples.

Breadth of Coverage

In 201 pages (not counting appendices, preface, etc.), Koskela articulates and demonstrates what has taken me years of experience to learn from writing and maintaining unit tests and from reading about unit testing. Even though the high-level concepts were not really new to me, I still learned several tactical approaches from this book. Besides learning some new tactics to employ to implement the concepts of unit testing in Java that I thought I already knew, this book has sparked additional ideas for improving my unit tests and has reinvigorated my interest in writing better unit tests.

Pragmatic Advice

I liked Koskela's pragmatism in this book. Some unit testing enthusiasts (or test-infected Java developers as he calls them in the book) can be overbearing in their enthusiasm and evangelism to the point where it's difficult to believe their claims. Koskela is obviously enthusiastic about unit testing, but seems to keep in mind one important truth: unit tests exist to benefit the quality of the design and code (the production code does not exist to benefit the unit tests). Koskela points out, for example, that there are cases where redundant unit test code might be easier to read and maintain than rigorously implementing DRY principles within test code at any cost.

Conclusion

I was a little apprehensive when I purchased Effective Unit Testing as part of Manning's MEAP, but I am glad that I did. This book delivered what I hoped for and I found Part 2 and Chapter 7 and Chapter 9 of Part 3 to be particularly useful for someone in my situation (relatively experienced Java developer looking for ideas to improve his or her unit testing). Although there wasn't a lot new to me at the highest level, there were a lot of interesting lower-level details that were new to me or were presented from a unique and interesting perspective. I also liked having these ideas I had from my own experiences laid out and articulated for me in printed form and I liked having these concepts being developed by the Java unit testing community all codified in a single book. The book packs a lot into 201 pages of regular text and the writing style is easy to read and understand. It is easy for me to recommend this book to Java developers who feel they have room to improve in writing of unit tests of Java applications. I also know many Java developers (including myself) who could benefit from reading this book.