Unit Testing – A Practical Definition

What is a Unit Test? First off, what is a Unit? Basically a Unit is a significant piece of a larger project. Unit Testing is specifically programmatically testing the back end programming or the front end programming and interface. These are typically just referred to as the Back End and the Front End. The Front End is often spoken of as including the “Design” (aka look and feel). Furthermore, a Back End designed to work with more than one Front End typically has a formal API (Application Programming Interface) and it is common to speak of the Back End simply as “The API” (i.e. “the API is rebooting right now”).

Now that we have all that spelled out, Unit Testing is almost always testing an API. A matching program is written to interface with the Back End and provide test data and check the response for validity. The best setups run the tests ever time a change is compiled or saved to the Back End code. This assures that the change in one part didn’t break that feature, or some other related or even supposedly unrelated feature. This is especially true when changing the structure of a database, since the effects are not always immediately obvious. Unit tests often save hours of trouble shooting because they reveal problems much closer to when they’re caused. And they save time at the end of a project, since it’s extremely time consuming and error prone to manually test projects after everything is written, and when the tests are all passing, running them one last time is very fast, so you’re project delivery time is much more predictable with good Unit Testing.

When a Back End only interfaces with one Front End, its functionality is often tested by testing the front end, kind of using the Front End as a manual test of the back end unit. Since unit testing a Front End is far more complex they are often not setup with automated unit tests, rather, they are manually tested using a checklist, or in some cases, just “spot checked” randomly hoping to catch bugs before the client or customers see them. Definitely better to have a methodical way to test, either manually, or with unit tests.

Mostly Unit Testing is implemented through TDD, Test Driven Design (aka Test Driven Development). TDD means the programmer writes tests that try to get specific responses from the API and they fail. Then he/she writes an API that provides the expected responses, so the tests pass. Then more tests are added, and more API features to match the tests, until all the desired features are functioning properly.

Take note of the “one feature at a time” design paradigm. This is part of Agile Development. If the project scope changes, all the unimplemented features may not need to be written, and everything that is already written is fully functioning. This makes much less waste when projects change (they almost always change). It is also easier to determine and explain the cost to change the scope of the project to a client because working unit tests prove to the client that progress has been made, justifying charging the cost of features they choose to remove from the project.

Another paradigm worth noting is Lean Development, which basically says to only build what you need. This may sound like Agile, however, the difference is that Lean eliminates features up front, reducing the complexity of the plan from the beginning, and Agile is a method of following a plan once that plan is in place. Lean also reviews projects to prevent and remove “feature creep”, that is when developers make features more capable than they have to be, therefore increasing the complexity and cost of developing and maintain those features. The best way to make code work well is to eliminate unnecessary code, keep it Lean.

So Unit Testing is a significant piece of the Lean & Agile Project Development of complex programs and web sites. It also happens to be a good idea for almost any project, even if it only has one unit, test that unit.

Commandline Redirection > & >>

Unix commands usually return results to the screen. Those results can be directed into a file instead, with > or >>. The first overwrites the file, the second appends to it.
ls > files_of_filenames.txt
ls >> files_of_filenames.txt

NOTE: > and >> are short forms of 1> and 1>>. 1 should be thought of as meaning stdout (Standard Output), which is almost always set to the terminal you’re typing commands on until you redirect it like this. There is also 2> and 2>> which do the same thing for stderr (Standard Error). If you don’t have permission, an error telling you so will print to stderr

To list the contents of the current folder, type the command ls. LS (in lower case letters) is short for “list” and will list the files in the current directory (like DIR on Windows).

ONE FINAL NOTE: >& 1 represents the setting where stdout is pointing.
ls 1> list.txt 2> list_errors.txt (Normal output in a file, errors in another)
ls 1> list.txt 2>& 1 (this will combine everything into one file)

This means a command like this directs to two files:
ls *  > outB.txt 2>& 1 1>outA.txt
stdout goes to outA.txt
stderr goes to outB.txt
First it sends stdout to outB.txt with > then directs stderr to where stdout is going, then redirects stdout again to outA.txt with 1> and even though there’s not reason to do this exact thing, there may be reasons in the flow of programs that “compile” pieces of a command into a final command, and this could be the result. Usually you’ll see 2>&1 with no spaces, however, I’ve added spaces to both prove it works, and to illustrate that 1 is an argument to 2>& and not just part of it.

Redirecting INPUTS
Also worth noting, there is a stdin (Standard Input) which is 0< and generally comes from the keyboard or can be from a file.
perl in-test.pl < list_of_inputs.txt

This is very different than command line arguments. When a script asks the user to answer a question interactively, a line from the file is read. In this way, a programmer can create a file to simulate a series of user inputs and feed it to stdin for testing.

In this example I wrote a perl script called in-test.pl which asks for 9 inputs in a row and prints them out once the users (or file) provides a line return (user hits enter). Here’s the script, just save it as in-test.pl and run perl with this file as it’s only argument as shown above. Even though the only argument to perl is in-test.pl and there are no arguments to the script either. The rest of the line is providing a series of inputs to the scirpt. The difference between an argument and an input is that arguments are all present at the start of the script, however, inputs are not present until the script asks for each of them.

in-test.pl

#!/usr/bin/perl
print “Input Test Script\n”;

foreach my $idx (1..9){
$input = <stdin>;
chomp $input; #removes the line return if it’s there
print “input($idx): $input-\n”;
}

list_of_inputs.txt

First Line of File.
Hi 2
Bye 3
More makes 4

Netflix is dead… long live Netflix.

Netflix – Making the right moves

What was that. Oh, a speed bump. DVDs via Netflix were a big improvement compared to Blockbuster rentals, but not compared to Streaming via Netflix. Hurray for the future of Netflix!

What could make it better? The option to download and watch where there’s slow or no connection. Seriously.

Continue reading

Apple’s Tablet is coming

With all these rumors, it’s a pretty sure thing. Some of the details are not certain, but some are. It should be a 10.1″ iPhone type device with a surprising interface. It might have a camera, or GPS, or compass. It might even respond to a stylus or Wacom pen.

Apple always makes great products by making great software for it. Being larger than an iPhone means changes that we can’t predict, so we won’t know what they are like until we see it.