It’s been a great week at JavaOne 2016! Here’s a photo I took just before Gwen Stefani and Sting came on stage at the Oracle Appreciation Event in the AT&T Park in San Fransisco, home of baseball’s World Series-winning San Francisco Giants. What a crowd! What a week.

The Librarian: Introduction to Test-Driven Development

This will be a series of articles revolving around unit testing where I will work through examples and exploring various aspects of the craft. This is the first installment.

The code associated with this article can be found on GitHub. Future and past installments can be found in The Librarian Archive.

I will try to implement a few requirements for a Library module with books and memberships, extending whatever code we have in a test-driven style (“TDD”) as we go along. I share a few thoughts about the process, show some refactorings and give a few hints for using the IDE.

The level of this article is for junior developers who want to expand their testing horizon.

There’s plenty of information out there which describes what TDD or Test-Driven Development is, the red-green-refactor cycle etc so I won’t delve into too much introductory detail here. See the references at the end for more background-information.

Instead, just get started!

So If You’re Using Tag Libraries for Your View Models You Have To Test Them, Right?

In a previous post I introduced thinking about (visual) components and used a Task Browser as an example of an user interface “component” .

I explained that using

• View Model(s) e.g. plain-old Groovy objects (POGOs) holding the related data e.g. a class TaskBrowser
• Tag Libraries (LayoutTagLib) and tags (def taskBrowser) to render the associated HTML (views/layouts/components/_taskBrowser.gsp) to the page

allows for more maintainable and testable code.

Let’s put our money where our mouth is and see how one could test the used tag library.

2 Rookie Java Constants and Enums Pitfalls

In various code reviews I perform on Java and Groovy code I often see magic numbers and other random Strings littered all over the code base.

A magic number, for example, is the 4.2 in below (Groovy) code snippet:

if (swashbuckle >= 4.2) {
  ...
}

What does 4.2 mean?

My advise is to extract such a number to a constant and give it a meaningful intention-revealing name, so that we can all keep understanding our code.

After refactoring into

if (swashbuckle >= MAX_ALLOWED_CAPACITY) {
  ...
}

even beginning developers understand the value of The Constant and start extracting values all over the place into constants. When I talk about enums it’s even more possible to write readable code, but quickly inexperienced developers quickly fall into the following traps.