Recently, I had a task to migrate the unit tests in our project from ‘JUnit 4’ to ‘JUnit 5’. As many developers, I researched a bit to learn about the major differences between the two versions and drafted a plan for smooth migration.

From the first look, I thought my only job was refactoring the tests and probably some helper classes. But, I was wrong! I ran into a configuration issue with the maven-surefire-plugin configuration.

In this post, I will be sharing the encountered issue and its fix. Note that I will not cover the detailed steps of how to migrate from ‘JUnit 4’ to ‘JUnit 5’.

Tests run: 0!

We, as many other developers, use the maven-surefire-plugin to run our tests during the test phase of maven’s build lifecycle. We rely heavily on this plugin because it fails the build when one of the tests is broken!

With JUnit4, everything was working perfectly! But after the migration, the plugin was always reporting that not tests are run:

'Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 ...'!

Calculator Class

For the purpose of this blog, let us assume we want to build a Calculator. For now, we only have the ‘add‘ method implemented as shown below.

The fast and constant change in technology made it inevitable for developers to always improve their skills through continuous learning. It is a fact now that developers with outdated skills will be left behind!

Learning isn’t the same for everyone. Some people may learn well by themselves; some may need instruction and example. In the programming world, many resources can meet those particular needs.

And using skills on projects that aren’t all imaginary is key too. Real world projects equal real world experience that translates into adapting more efficient, effective programming language.

What else helps to improve programmers’ skills and help them continue to move into the next wave-whatever that may be? I found this graphic that explains tactics, solutions, and ideas to pursue.

Personally, I have been following some of those for the past couple of years to improve my technical and soft skills!

As a developer, there is a high chance that you had a debate on the value of TDD in building software, especially if you apply it!

I had a lot of those debates!

A couple of months ago, I came across such a debate between Jim Coplien and Robert Martin (Uncle Bob). I found this discussion kind of interesting especially that it involves two leaders in software engineering.

You can watch the debate here:

Takeaways

Here are my takeaways from the discussion:

Three Rules of TDD

Uncle Bob defines the following three rules for applying TDD:

Don’t write a line of production code without having a corresponding failing test

Don’t write too many failing tests without writing production code

Don’t write more production code than is sufficient to pass the currently failing test

Architecture is Important

Jim points out that he has no problem with those rules, his concerns are more architecture related. Jim and Uncle Bob would argue for more than ten minutes to finally reach an agreement on the importance of architecture. The below five points summarizes what they agreed on:

Architecture is very important

It is entirely wrong to assume that the code will assemble itself magically just by writing a lot of tests and doing quick iterations

Design evolves with time and should be assembled one bit at a time

An Object should have properties to give it meaning. At the beginning, those properties should be minimal.

Architecture shouldn’t be created based on speculation

TDD and Professionalism

Probably the only disagreement you can sense from this debate is what defines a professional software engineer. For Uncle Bob, it is irresponsible for a software engineer to deliver a single line of code without writing a unit test for it. Jim, on the other hand, considers ‘Design by Contract’ to be more powerful than TDD.

My Point of View!

Personally, I have been applying TDD since I joined my team three years ago. After experiencing the benefits of this practice, we got to a point where we don’t write or refactor any line of code without having a corresponding unit test!

In addition to that, I had the chance to coach other developers by running coding dojo sessions at work.

All that makes me say that I agree more with Uncle Bob on the topic of professionalism!

Of course, you’ve heard this question many times before and probably your answer will slightly differ from your teammates’. But, with the help of two agile team-building activities, you can eliminate such a difference and reach an alignment with your teammates on a description for your team and product. Those activities are ‘Collaborative Product Vision‘ and ‘Defining the Team Vision Statement.’

Ask each group to present and explain (if needed) the vision they came up with

For each blank, ask the team members to individually vote for their favorite replacement

Replace each blank with the phrase of highest votes

Read the new statement out loud

With the team apply some changes if needed

The Benefits

I am writing this blog because I think this is a nice activity for any team! So far, I have played it with three different teams, existing and newly established ones.

Here are some benefits of playing this activity:

Good activity for team bonding especially new ones

Aligns all team members on one vision of the product they are building

Aligns all team members on what is considered as in and out of scope of the product

Helps teams in identifying their main competitors

Highlights the major difference between the product and its competitors

A short but meaningful description of the product for upper management, visitors, and newcomers

Example

FOROutlook Users WHOwant to keep track of time spent in meetingsTHE MeetingReporterIS An outlook-addinTHAT generates time reports from the calendar UNLIKE existing tools where you have to manually insert time spentOUR PRODUCTwill parse the calendar and automatically generate different reports based on meeting category

Above is an example!

It is the vision of the tool I am writing on my free time! From this short statement and without any further explanation, anyone should understand purpose and major feature of this tool!

Finally

Some people consider such activities as a waste of time. Obviously, I disagree! This is an occasional activity that takes between 15 to 20 minutes depending on the team’s size. Thus, it is an excellent candidate for the first activity of the team’s retrospective!

I encourage teams to try it. For those who do, I am pretty sure you will be posting the outcome on your team’s home page, just as we did!

In my previous post, I explained the different types of exceptions in Java and left two questions for this post!

Which exception to use?

Java documentation and Uncle Bob’s book (Clean Code) were my references when preparing this tutorial. I noticed a slight difference between what is recommended in each!

Java Documentation

While reading the Java documentation, you sense a preference for Checked Exceptions. The documentation states that the usage of UnChecked Exceptions should be restricted to the case where crashing the system is intentional if an exception occurs. In other cases where recovery is still possible, Checked Exceptions should be used.

Robert Martin’s opinion

Uncle Bob has a different opinion! He argues that although Checked Exceptions might have some benefits and can be useful in some special cases like writing critical libraries, they are not a necessity to have a robust software.

Breaking the ‘Open/Closed Principle‘ and ‘Encapsulation‘ are the main two reasons that make using Checked Exceptions a bad idea!

Let’s see how!

In the below example, the MainBookReader.main method is calling the method MainBookReader.readJsonObject to get the book’s description from a JSON file. And since readJsonObject throws an exception we had to add throws FileNotFoundException clause to the signature of the main method and the interface JsonLoader!

Don’t pass null

In your code, you shouldn’t pass null as parameters and instead use the Special Cases as before. But, it gets harder to prevent your clients from passing nulls thus you might need to assert some function parameters before proceeding with your code execution!

Finally

Doing the refactoring for the simple example above might look like over-engineering! But, it becomes beneficial when writing more complex code!

I think that the excessive usage of CheckedExceptions will pollute the code and thus should be avoided! For me, the benefits of CheckedExceptions can still be achieved through:

Following the rules of Clean Code

Increase test coverage of the code by following the TDD practice! With the use of TDD, all the edge cases should be covered and thus eliminating the possibility of having unexpected exceptions during execution!

To understand better the importance and how to write clean code, it is highly recommended that you read the book Clean Code by Robert Martin!

Reading the chapter ‘Error Handling‘ from the book ‘Clean Code‘ made me think whether developers follow the clean code rules when writing production code. It also appeared to me that the difference between the Java exception types might not clear be for some!

The purpose of this short tutorial is to clarify those two points. And to make it clearer, I will be dividing it into two posts. In the first one, I will explain the different types of Java exceptions. Whereas in the second one, I will show how to write clean exception code!

Java Exceptions

In Java, the class Throwable is at the top of the class hierarchy of all exceptions. The classes Error and Exception directly extend Throwable. All the subclasses of Error and Exception are grouped into two types ‘Checked Exceptions‘ and ‘UnChecked Exceptions‘as displayed in the image below.

What is the difference between Checked and UnChecked Exceptions?

UnChecked Exceptions

UnChecked Exceptions extend the classes ‘Error‘ or ‘RuntimeException‘. In this case, developers don’t have to worry about catching or handling the exceptions at compile time as the compiler won’t report any error. But, as they are not caught, those exceptions may result in complete failure of the application when thrown during execution.

1. Runtime Exception

The code is fine and will compile with no errors! So what is the problem?

The problem might occur at runtime if we try to call the method while passing zero as the denominator. Since this exception is not caught, our system will crash throwing the below arithmetic exception:

Checked Exceptions

On the other hand, all other classes extending the ‘Exception‘ class are considered to be Checked Exceptions. In this case, the code will not compile if the developer doesn’t explicitly handle the exception.

This adds a level of security to your code, as you are forced to specify how your code should behave when an exception occurs and thus decreases the chance of having an unrecoverable failure in the system.

I hope this post gave you a better understanding of Java exceptions! In the 2nd part, I will be sharing more details on how to properly write exceptions in clean code and which of the two exception types to use!

LeanStartup board game

The purpose of this game is to introduce participants to the practices and principles of Lean-Startup by simulating a business where each group has to produce a product and sell it to customers.

Game Rules

In the beginning, the game seemed a bit complex or vague, but things started to get clearer after the second iteration. Here are some of the game rules:

Split the participants into four teams (ideally three per team)

Each team is a functional company responsible for building a product

The board represents the market, where each is a customer requesting some features

At each turn, the team can distribute their resources on building features, investing in their company, experimenting or selling a feature

Through experimenting, the team can flip a tile to learn the requirements to sell the feature.

At each experiment, all the participants get the chance to learn new vocabulary from the lean-startup!

The team who reaches the red tile (in the middle of the board) first wins the game.

LeanStartup Vocabulary

During the session, we came across many lean-startup vocabularies, but here I will only be mentioning five of them!

Pivot or Preserve: Certain challenges might force entrepreneurs to make a major change in their strategy. That change is called a Pivot!

Idea Theft: Finding a compromise between the fear of idea theft (someone stealing your idea) and gaining knowledge is not an easy task. But, it is more important to gain knowledge than being afraid of spreading your idea!

Concierge MVP: In some cases, you might need to create a fake processing MVP. That means what is happening in the background is not what it looks!

Startup Machine: Put your idea to test by going to streets and asking people what they think about the product

Startup Weekend: This is an activity where people of different backgrounds (dev, marketing, designers, etc.) meet to start building the first version

Take Aways

This game can be played by startups or even teams at large enterprises! And at the end, players should have got an idea of what Lean-Startup is. And more importantly, they will learn some of the factors that can play a role in any team’s failure or success such as competition, luck, technical excellence, failing and successful experiments, etc.

Agile Self-Assesment Game

As the name indicates, this game helps teams to assess how agile they are.

The game can be played by either an existing or a new team. In the case of an existing team, the results can be a base for a plan to change or improve their agile process. Whereas, for a new team this activity can be considered a futurespective activity as it defines the team’s first iteration.