Unit Test Cases

One strong point of unit tests is when modifications are made to code, a unit test can quickly ensure that a function or method is not broken. In my past work experience, developing unit tests aren’t put into practice. Typically, the following happens:

1. I make a code change.
2. I test the code change from an end-user standpoint to verify that the change works as expected.
3. A person from the testing or quality assurance department verifies that the change works as expected.

One of the main challenges in modifying existing complicated code is you could inadvertently impact another piece of the application that uses a function or method in a negative manner no matter how careful you are. In scenarios where this negative impact is undetected, more time is spent rolling back (undoing) the code change, correcting corrupted data, and redeploying another correction. Creating and using unit tests are another safeguard in preventing unwanted, time wasting, situations like this. In more extreme cases, if a method or function is completely rewritten, a unit test case can quickly confirm that the revised code is working as desired.

Below, I’ve created a test case for a function that generates an array of Fibonacci numbers. Refer to my previous blog entry for more information about it.

require 'test/unit'
# File that holds the generate_fibonacci_seq method
require 'fib.rb'

# Unit test cases for a function which computes Fibonacci numbers
# Refer to my previous blog entry for more details concerning
# the implementation of generate_fibonacci_seq
class FibTest < Test::Unit::TestCase

  # Initializes instance variable(s) used for each test case.
  # Before a unit test case method is run, setup() is invoked.
  def setup
    # A correct computation of the first 32 Fibonacci numbers from
    # obtained from another website
    @correct_fibonacci_seq = [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144,
                              233, 377, 610, 987, 1597, 2584, 4181, 6765, 10946,
                              17711, 28657, 46368, 75025, 121393, 196418, 317811,
                              514229, 832040, 1346269]
  end

  # Tests the validity of the first 32 Fibonacci numbers
  def test_fibonacci_seq_32
    test_array = generate_fibonacci_seq(31)

    # Ensure that the generated array contains 32 numbers
    if (test_array.size != 32) then
      flunk("Generated Fibonacci sequence must contain 32 numbers.")
    end

    i = 0
    for test_element in test_array
      # Displays a custom output messag showing which index in the array
      # did not match
      assert_equal(test_element, @correct_fibonacci_seq[i],
                   "Item at element " + i.to_s + " did not match.")
      i = i + 1
    end
  end

  # Tests the scenario when a user enters a negative number
  # into generate_fibonacci_seq()
  def test_fibonacci_seq_neg
    test_array = generate_fibonacci_seq(-1)

    assert_equal(test_array, Array.new)
  end

  # Tests the scenario when a user enters a zero
  # into generate_fibonacci_seq()
  def test_fibonacci_seq_0
    test_array = generate_fibonacci_seq(0)

    assert_equal(test_array, [0])
  end

  # Spot checks the a few Fibonacci numbers
  def test_fibonacci_seq_at_100
    test_array = generate_fibonacci_seq(99)

    # Ensure that the generated array contains 100 numbers
    if (test_array.size != 100) then
      flunk("Generated Fibonacci sequence must contain at 100 numbers.")
    end

    # Test that the hundredth number is correct
    assert_equal(test_array[99], 218922995834555169026)

    # Test that number 75 is correct
    assert_equal(test_array[74], 1304969544928657)

    # Test that number 42, the meaning of life, is correct
    assert_equal(test_array[41], 165580141)
  end

end

One amusing thing about creating test cases is that there’s a method named flunk to flag that a test failed. I use flunk enforce that the size of the arrays are correct.

In the test_fibonacci_seq_32 test case, I manually loop through each element instead of passing in the entire array to assert_equal. This way I can display a custom message stating which index into the array did not match. I found that passing arrays into assert_equal caused a failure to regurgitate both arrays in the output. I didn’t feel like sifting through sixty-four numbers to figure out which two did not match.

The four tests done in this unit test case generates the following output.

Loaded suite FibTest
Started
….
Finished in 0.001782 seconds.

4 tests, 37 assertions, 0 failures, 0 errors