Understanding the unit test

What is a unit of code? A unit is an isolated collection of code. A unit can be tested without loading or running the entire application. Usually, it is just a function. It is easy to determine what a unit is when dealing with code that is well organized into discrete and encapsulated modules. On the other hand, when code is splintered into ill-defined chunks that have cross-dependencies, it is difficult to isolate a logical unit.

What is a test? A test is code whose purpose is to verify other code. A single test case, (often referred to as an example in the RSpec community) consists of a set of inputs, one or more function calls, and an assertion about the expected output. A test case either passes or fails.

What is a unit test? It is an assertion about a unit of code that can be verified deterministically. There is an interdependency between the unit and the test, just as there is an interdependency between application code and test code. Finding the right unit and writing the right test go hand in hand, just as writing good application code and writing good test code go hand in hand. All of these activities occur as part of the same process, often at the same time.

Let's take the example of a simple piece of code that validates addresses. We could embed this code inside a User model that manages a record in a database for a user, like so:

Class User

  ...
  
  def save
    if self.address.street =~ VALID_STREET_ADDRESS_REGEX &&
       self.address.postal_code =~ VALID_POSTAL_CODE_REGEX &&
       CITIES.include?(self.address.city) &&
       REGIONS.include?(self.address.region) &&
       COUNTRIES.include?(self.address.country)
       
       DB_CONNECTION.write(self)
       
       true
     else
       raise InvalidRecord.new("Invalid address!")
     end
    end
   
   ...
   
  end

Writing unit tests for the preceding code would be a challenge, because the code is not modular. The separate concern of validating the address is intertwined with the concern of persisting the record to the database. We don't have a separate way to only test the address validation part of the code, so our tests would have to connect to a database and manage a record, or mock the database connection. We would also find it very difficult to test for different kinds of error, since the code does not report the exact validation error.

In this case, writing a test case for the single User#save method is difficult. We need to refactor it into several different functions. Some of these can then be grouped together into a separate module with its own tests. Finally, we will arrive at a set of discrete, logical units of code, with clear, simple tests.

So what would a good unit look like? Let's look at an improved version of the User#save method:

Class User


  def valid_address?
    self.address.street =~ VALID_STREET_ADDRESS_REGEX      &&
      self.address.postal_code =~ VALID_POSTAL_CODE_REGEX  &&
      CITIES.include?(self.address.city)                   &&
      REGIONS.include?(self.address.region)                &&
      COUNTRIES.include?(self.address.country)
  end

  def persist_to_db
    DB_CONNECTION.write(self)
  end

  def save
    if valid_address?
      persist_to_db 
      true
    else
      false
    end
  end

  def save!
    self.save || raise InvalidRecord.new("Invalid address!")    
  rescue
    raise FailedToSave.new("Error saving address: #{$!.inspect}")
  end

...

end

Therefore, we write unit tests for two distinct reasons: first, to automatically test our code for correct behavior, and second, to guide the organization of our code into logical units.

Automated testing has evolved to include many categories of tests (for example, functional, integration, request, acceptance, and end-to-end). Sophisticated development methodologies have also emerged that are premised on automated verification, the most popular of which are TDD and BDD. The foundation for all of this is still the simple unit test. Code with good unit tests is good code that works. You can build on such a foundation with more complex tests. You can base your development workflow on such a foundation.

However, you are unlikely to get much benefit from complex tests or sophisticated development methodologies if you don't build on a foundation of good unit tests. Further, the same factors that contribute to good unit tests also contribute, at a higher level of abstraction, to good complex tests. Whether we are testing a single function or a complex system composed of separate services, the fundamental questions are the same. Is the assertion clear and verifiable? Is the test case logically coherent? Are the inputs and outputs precisely specified? Are error cases considered? Is the test readable and maintainable? Does the test often provide false positives (the test passes even though the system does not behave correctly) or false negatives (the test fails even though the system works correctly)? Is the test providing value, or is it more trouble than it's worth?

In summary, testing begins and ends with the unit test.