Unit Testing

Quick Index

Unit Testing Lingo/Jargon
Overview
General Unit Test Pattern 💡
Showstopper Bugs 🐞
Smoke Tests 🔥
Functional Test
Testing Lessons Learned
Test Code Styles
Simple Unit Test Examples

	Word	Meaning
🚙	Unit	The unit of code (e.g., a class) being tested -- examples may be Car, Employee, City, Student, Instructor, Course, ... (whatever your modeling domain subject is)
🚙	Model	Another name for unit
💡	Unit Test	A class that contains tests that test the unit -- generally named CarTest, EmployeeTest, etc

💥	Showstopper Bug	A bug that prevents a program from starting/running or stops it from functioning (program crash)
🐞	Functional Bug	A bug that causes a program to not behave (function) as expected
🐞	Defect	Another name for bug

✔	Unit Testing	The act of testing a unit of code -- e.g., we may have a CarTest class (unit test) that tests a Car class (unit)
🚗	Automated Testing	Applying automation to unit testing -- e.g., running a collection of tests automatically which generates a test report/output
🔥	Smoke Testing	A subset of unit testing where the focus in on catching showstopper bugs

Overview

Unit tests are simply program code (dtest) that tests (domain) program code.

We call them "unit tests" because we are testing units (objects/models).

Generally we tests something like:

RectangleTest for domain model Rectangle
DynamicArrayName for domain model DynamicArray

The unit test name is not an exact science -- these are only suggested names.

General Unit Test Pattern 💡

Tests basically follow this "1-2-3" pattern:

Construct object to be tested (testee)
Send message(s) to testee
Compare testee actual results versus expected results

Note: The software test "comparison" can be basic (print that allows a visual compare) or more sophisticated (e.g., showing "test passes", "test fails").

Showstopper Bugs 🐞

Story of a Showstopper Bug

Imagine we have spent weeks building an elaborate generator for a fractal coding contest.

We're very proud of it.
We submit our code and anxioiusly wait feedback from the coding judges.
The feedback arrives -- they could not run our program! It crashed.

This is the heartbreaking story of what showstopper (blocker) bugs can do. They can completely stop the show.

Fortunately, smoke tests help us avoid these unpleasant creatures.

What Are Showstopper Bugs?

Note: we will use "showstopper bug" and "blocker bug" interchangeably:

By showstopper bug we mean stop the show (i.e., stop the program from running), by blocker bug, we mean block the program from running. I.e., they both mean "stop the program from running".

Showstopper bugs are the enemy of coders:

We may have the prettiest code in the world, but one showstopper bug can make our code unusable
In the software field, unusable code causes delays and headaches
In coursework, unusable code results in scores of zero -- in fact, it is better to submit code 25% done with zero showstopper bugs than code 99% done with one showstopper bug

Examples

A few examples of common showstopper bugs:

Classes have compile errors
Incorrect class headers
Incorrect constructor method headers
Bugs in constructors
Classes in the wrong packages/sub-directories
Incorrect filenames
Incorrect sub-directory names
Incorrectly designating a class or method as non-public

Patterns

These nasty showstopper bugs follow a couple patterns:

Prevent code from running
Prevent objects from being constructed

Avoiding Showstopper Bugs 😊

We can easily avoid showstopper bugs.

We just need to to do things:

Check and recheck that housekeeping items match what is expected -- e.g., required package/sub-directory names, class names, class headers, method headers, constructor headers
Run smoke tests

Smoke Tests 🔥

Purpose

We just learned about not-so-friendly showstopper bugs.

The single purpose of smoke tests is:

Catch (identify) showstopper bugs (so that we can fix them before delivering unusable code).

Definition

Basic Definition

We define smoke tests as a subset of unit tests
Purpose is to catch (identify) showstopper bugs
Unit tests (in entirety) help assure that software is running correctly while smoke tests (subset of unit tests) focus on showstopper bugs
Smoke tests exercise the code more than testing it
Smoke tests chiefly focus on assuring that program starts, program (core functionality) runs, objects can be created/constructed

Examples

Functional Test

After smoke testing, we have "functional testing" -- e.g., "Is our software giving the correct answers?"

Functional tests compare actual results vs expected results.

Functional tests "cover" as many public methods as possible. Ideally, there is one or more functional tests for each public method.

Testing Lessons Learned

Start with 'Smoke Tests' to Find 'Blocker Bugs'

First make sure that simple "smoke tests" pass.

Continue with Functional Testing

After smoke tests are passing, then add functional tests (which compare "actual" vs "expected" results).

Do Not Put Test Code in Same Directory as Domain/Model Code

Graders and object will be using/testing our objects from "other" directories (and importing our files as needed) so we want to do similar. Otherwise, there is a good chance we'll miss bugs that they will hit (and these could be "blocker bugs").

If we put our test code in another directory (apart from our model/domain) then we will exercise/test required "imports" etc of our code.

By domain/model we mean our data structures (e.g. dynamic arrays, linked lists, trees, etc).

Test Objects (Not Just Primitives)

When testing a data structure we do not want to just test primitive element types like integers, strings, etc.

We also want to make sure our data structures work with "proper objects". These can be anything (e.g. customers, employees, stars, books, etc.).

We generally want to design the object types (classes) to have a unique key (e.g. customer number, employee number, star id, book ISBN, etc).

Equals Over '=='

Generally in object languages the operator "==" works for primitive values only (not proper objects).

So in your test code (and domain code) you should try to use the flavor an available version of "equals".

To support object equality, you will also likely need to implement "equals" in any object types (classes) you are using for tests.

Collections Take Special Care

We need to take special care when comparing collections.

We will need to verify that our equality checks are working for something like "collection1.equals(collection2)".

We may need to add helper/support methods to get these checks to work properly.

Test Code Styles

Overview

Test code can be simple to sophisticated.

It does not need to be sophisticated to be useful, especially for small projects.

Example Tests (Different Test Strategies)

These examples are in Java syntax but the ideas apply to other objects languages like JavaScript, etc.

Examples are here...

Simple Unit Test Examples

Overview

This page contains a couple simple unit test examples.

Examples

The examples are in pseudocode.

Convert them to your specific language (Js, Java, etc) to meet the syntax of your language. Especially note:

Imports, etc will need to be added to your test in the usual way per the given coding language
"this.show" in the examples can be converted to "console.log", "System.out.println", etc, per the given coding language

Example 1 -- Testing with Primitives

Example Pseudocode

Testing with primitives (e.g. integers, strings, doubles) is an okay way to get started testing. But see "lessons learned" on testing with "proper objects".

class DynamicArrayTest  {

	test_get_usingStrings() {

		let nm1 = 'Asha';
		let nm2 = 'Kofi';
		let dynamic = DynamicArray.newEmpty();
		dynamic.add(nm1);
		dynamic.add(nm2);
	
		var result, expected;
	
		result = dynamic.get(0);
		expected = nm1;
		this.show(result.toString());
		this.show(expected.toString());
	
		result = dynamic.get(1);
		expected = nm2;
		this.show(result.toString());
		this.show(expected.toString());
	
		//we could also test "first" and "last" the same way
	}
	
	//...
}

Example 2 -- Testing with Proper Objects

Example Pseudocode

You'll need to also code a testee object (to test with) -- in this example we use "Customer" -- download here for an example....

class DynamicArrayTest  {

	test_get_usingProperObjects() {

		let customer1 = Customer.fromFnameLnamePhoneZip('Kofi', 'Lee', '1112223333', 55100);
		let customer2 = Customer.fromFnameLnamePhoneZip('Asha', 'Woods', '9991231234', 55300);
		let dynamic = DynamicArray.newEmpty();
		dynamic.add(customer1);
		dynamic.add(customer2);

		var result, expected;

		result = dynamic.get(0);
		expected = customer1;
		this.show(result.toString());
		this.show(expected.toString());

		result = dynamic.get(1);
		expected = customer2;
		this.show(result.toString());
		this.show(expected.toString());
	}
	
	//...
}

Unit Testing (Chapter 102 - Unit Testing)

CHAP101 < Unit Testing

Chapter Top Search Site TOC