Skip to main content

Unit Testing Tip: Break steps into separate methods

Testing in the Trenches (TinT) is a series of posts adapted from real-world discussions and advice I have given to teams and individuals struggling to adopt Unit Testing habits and best-practices.

The Method is an important basic unit of unit-testing. If you have a tendency to write entire processes or algorithms as single, large methods, you will find a lot of benefits to breaking them into smaller steps in separate methods. Unit tests for these smaller methods are easier to write, and are key for proving the validity of each step in the larger process.

For example: We have an Enhancement Specification that says the program should behave one way if a given Rule has never yet been applied, and behave another way if the Rule has already been applied one or more times.

This distinction of "already used or not" is a key condition that appears many times in this spec.

We can check for the condition with something like this:
if (myrecord.getAsString(lastPledgeDate).isEmpty())
     // do the Never Yet Used thing
else
     // do the Already Used thing

We could use that condition right in the algorithm whenever it is needed, but there are some good reasons not to (see below). Instead, pull that condition into a separate method:

public boolean hasRuleBeenUsedAtLeastOnce()
{
     return !myrecord.getString(lastPledgeDate).isEmpty();
}

In the above method, the check has been inverted, since it lets the calling code express a positive (hasRuleBeenUsedAtLeastOnce()) rather than a negative (e.g. hasRuleNeverBeenUsed() )

This method is short and sweet. Is it too simple? Maybe, but see below for its benefits. To unit-test this method, we would need at least one case where the data field has data and one where it does not. So after creating a jUnit test class, add:

@Test
public void hasRuleBeenUsedAtLeastOnce_BlankDate_NeverUsed()
{
      setLastPledgeDate("");
      Rule r = new Rule();
      assertFalse(r.hasRuleBeenUsedAtLeastOnce());
}

@Test
public void hasRuleBeenUsedAtLeastOnce_NonBlankDate_HasBeenUsed()
{
      setLastPledgeDate("20160810");
      Rule r = new Rule();
      assertTrue(r.hasRuleBeenUsedAtLeastOnce());
}

Does this seem like too simple and trivial a chunk of code to pull into a separate method? Here are some benefits to doing so:

1. It makes the calling code more readable and therefore easier to understand, maintain and debug.

Consider the difference between these two conditional statements, when you read them in some code,:

if (myrecord.getString(lastPledgeDate).isEmpty())
vs.
if (rule.hasRuleBeenUsedAtLeastOnce())

The first is at a lower level of detail. Reading it drags our brain into the guts of data structures and data types. The second, with a higher level of abstraction, lets our thinking stay focused on the algorithm we are reading.

2. It is re-usable.

Imagine that, next year, the definition changes for how we know if a Rule has ever been used. With this method, the change this would require happens in one place. Without it, we'd have to hunt for and change the dozens of places that did the check the low-level way. And if we miss any, we'll introduce a new bug.

3. It is more Object-Oriented.

Now the responsibility for telling if the Rule has been applied yet or not belongs to the Rule class itself. None of the calling classes need to know or care about how it is determined.


4. And of course it is more testable!

Popular posts from this blog

How to do Git Rebase in Eclipse

This is an abbreviated version of a fuller post about Git Rebase in Eclipse. See the longer one here : One side-effect of merging Git branches is that it leaves a Merge commit. This can create a history view something like: The clutter of parallel lines shows the life spans of those local branches, and extra commits (nine in the above screen-shot, marked by the green arrows icon). Check out this extreme-case history:  http://agentdero.cachefly.net/unethicalblogger.com/images/branch_madness.jpeg Merge Commits show all the gory details of how the code base evolved. For some teams, that’s what they want or need, all the time. Others may find it unnecessarily long and cluttered. They prefer the history to tell the bigger story, and not dwell on tiny details like every trivial Merge-commit. Git Rebase offers us 2 benefits over Git Merge: First, Rebase allows us to clean up a set of local commits before pushing them to the shared, central repository. For ...

Git Reset in Eclipse

Using Git and the Eclipse IDE, you have a series of commits in your branch history, but need to back up to an earlier version. The Git Reset feature is a powerful tool with just a whiff of danger, and is accessible with just a couple clicks in Eclipse. In Eclipse, switch to the History view. In my example it shows a series of 3 changes, 3 separate committed versions of the Person file. After commit 6d5ef3e, the HEAD (shown), Index, and Working Directory all have the same version, Person 3.0.

Scala Collections: A Group of groupBy() Examples

Scala provides a rich Collections API. Let's look at the useful groupBy() function. What does groupBy() do? It takes a collection, assesses each item in that collection against a discriminator function, and returns a Map data structure. Each key in the returned map is a distinct result of the discriminator function, and the key's corresponding value is another collection which contains all elements of the original one that evaluate the same way against the discriminator function. So, for example, here is a collection of Strings: val sports = Seq ("baseball", "ice hockey", "football", "basketball", "110m hurdles", "field hockey") Running it through the Scala interpreter produces this output showing our value's definition: sports: Seq[String] = List(baseball, ice hockey, football, basketball, 110m hurdles, field hockey) We can group those sports names by, say, their first letter. To do so, we need a disc...

Updating Oracle javapath symlinks on Windows

A Java-based application on my Windows 10 machine recently started prompting me to upgrade my version of Java. Since I wanted to control it myself, I declined the app's offer to upgrade for me, and downloaded and installed the latest Java 8 from Oracle. In my case, Java 1.8.0_171, 64-bit version. The upgrade went fine. But when I launched the app, it again said I needed to upgrade. Why was it still looking at the old location? I made the change using Settings, to change the JAVA_HOME environment variable to point to the location of the new upgrade. But no change, the app still insisted that I needed to upgrade. A little research into the app's execution path showed that it was using c:\ProgramData\Oracle\Java\javapath to find Java. When I looked in that folder, I found symbolic links to my old Java installation. Normally, this hidden bit of information gets updated automatically in the upgrade or installation process. I have read of cases where, when downg...

Trigger Windows Scheduled Task from Remote Computer via Jenkins

One thing I love about working in Information Technology is the opportunity - the NEED - to constantly learn new things. If a week goes by in which I have not looked up something on StackOverflow or other message boards, I start lobbying my team for more challenges. This week, I learned the power of running " SCHTASKS.exe " from a command-line script for a remote server in a Microsoft Windows environment. If you don't know Schtasks, you can read up on it here: https://msdn.microsoft.com/en-us/library/windows/desktop/bb736357(v=vs.85).aspx In a nutshell, it is the command-line interface for the Windows Task Scheduler, and allows you (or a system administrator) to create, change, run, query, terminate, and delete scheduled tasks on a work-station, either the local one or a remote one. Not all of the features are available in older versions. In my scenario below, this was relevant as the local computer will be a Windows 8 machine, and the remote server is, shall we ...