An experimental new touch screen, the Obake, has a stretchable surface that to reacts user interaction in new ways.

An inexpensive new prototype device called the Obake adds a new dimension to touch screen technology. The surface of the device, developed by Dhairya Dand and Rob Hemsley of the MIT Media Lab, can react to how it’s being used by reaching out toward the user. It was relatively simple to make: the researchers used an open source software framework to enable the screen to react; the hardware costs between $50 and $60, Dand says.

Join the Department of Dance, Friday, May 3 at 8:00 p.m. in Studio 317 of the Fine Arts Building, as Dance students debut their first ever choreographic pieces for this First Works concert.

Admission to First Works is free.

Did you see something at URCAD and wondered how to get started in research?

Wed, May 1, 2013
Acad IV-A Rm. 114B
Noon to 1:00 pm

Join us and we will try to get you started with your undergraduate research/projects.

by Dawn Biehler

Writing shell scripts is very much like programming. Some scripts require little time investment; whereas, other complex scripts may require thought, planning and a larger commitment. From this perspective, it makes sense to take a test-driven approach and unit test our shell scripts.

To get the most out of this tutorial, you need to be familiar with the command line interface (CLI); you may want to check out the The Command Line is Your Best Friend tutorial if you need a refresher. You also need a basic understanding of Bash-like shell scripting. Finally, you may want to familiarize yourself with the test-driven development (TDD) concepts and unit testing in general; be sure to check out these Test-Driven PHP tutorials to get the basic idea.

Prepare the Programming Environment

First, you need a text editor to write your shell scripts and unit tests. Use your favorite!

We will use the shUnit2 shell unit testing framework to run our unit tests. It was designed for, and works with, Bash-like shells. shUnit2 is an open source framework released under the GPL license, and a copy of the framework is also included with this tutorial’s sample source code.

Installing shUnit2 is very easy; simply download and extract the archive to any location on your hard drive. It is written in Bash, and as such, the framework consists of only script files. If you plan to frequently use shUnit2, I highly recommend that you put it in a location in your PATH.

Writing our First Test

For this tutorial, extract shUnit into a directory with the same name in your Sources folder (see the code attached to this tutorial). Create a Tests folder inside Sources and added a new file call firstTest.sh.

#! /usr/bin/env sh
    
    ### firstTest.sh ###
    
    function testWeCanWriteTests () {
    	assertEquals "it works" "it works"
    }
    
    ## Call and Run all Tests
    . "../shunit2-2.1.6/src/shunit2"
    

Than make your test file executable.

$ cd __your_code_folder__/Tests
    $ chmod +x firstTest.sh
    

Now you can simply run it and observe the output:

$ ./firstTest.sh
    testWeCanWriteTests
    
    Ran 1 test.
    
    OK
    

It says we ran one successful test. Now, let’s cause the test to fail; change the assertEquals statement so that the two strings are not the same and run the test again:

$ ./firstTest.sh
    testWeCanWriteTests
    ASSERT:expected:<it works> but was:<it does not work>
    
    Ran 1 test.
    
    FAILED (failures=1)
    

A Tennis Game

You write acceptance tests at the beginning of a project/feature/story when you can clearly define a specific requirement.

Now that we have a working testing environment, let’s write a script that reads a file, makes decisions based on the file’s contents and outputs information to the screen.

The main goal of the script is to show the score of a tennis game between two players. We will concentrate only on keeping the score of a single game; everything else is up to you. The scoring rules are:

• At the beginning, each player has a score of zero, called “love”
• First, second and third balls won are marked as “fifteen”, “thirty”, and “forty”.
• If at “forty” the score is equal, it is called “deuce”.
• After this, the score is kept as “Advantage” for the player who scores one more point than the other player.
• A player is the winner if he manages to have an advantage of at least two points and wins at least three points (that is, if he reached at least “forty”).

Definition of Input and Output

Our application will read the score from a file. Another system will push the information into this file. The first line of this data file will contain the names of the players. When a player scores a point, their name is written at the end of the file. A typical score file looks like this:

John - Michael
    John
    John
    Michael
    John
    Michael
    Michael
    John
    John
    

You can find this content in the input.txt file in the Source folder.

The output of our program writes the score to the screen one line at a time. The output should be:

John - Michael
    John: 15 - Michael: 0
    John: 30 - Michael: 0
    John: 30 - Michael: 15
    John: 40 - Michael: 15
    John: 40 - Michael: 30
    Deuce
    John: Advantage
    John: Winner
    

This output can be also found in the output.txt file. We will use this information to check if our program is correct.

The Acceptance Test

You write acceptance tests at the beginning of a project/feature/story when you can clearly define a specific requirement. In our case, this test simply calls our soon-to-be-created script with the name of the input file as the parameter, and it expects the output to be identical with the hand-written file from the previous section:

#! /usr/bin/env sh
    
    ### acceptanceTest.sh ###
    
    function testItCanProvideAllTheScores () {
    	cd ..
    	./tennisGame.sh ./input.txt > ./results.txt
    	diff ./output.txt ./results.txt
    	assertTrue 'Expected output differs.' $?
    }
    
    ## Call and Run all Tests
    . "../shunit2-2.1.6/src/shunit2"
    

We will run our tests in the Source/Tests folder; therefore, cd .. takes us into the Source directory. Then it tries to run tennisGamse.sh, which does not yet exist. Then the diff command will compare the two files: ./output.txt is our hand-written output and ./results.txt will contain the result of our script. Finally, assertTrue checks the exit value of diff.

But for now, our test returns the following error:

$ ./acceptanceTest.sh
    testItCanProvideAllTheScores
    ./acceptanceTest.sh: line 7: tennisGame.sh: command not found
    diff: ./results.txt: No such file or directory
    ASSERT:Expected output differs.
    
    Ran 1 test.
    
    FAILED (failures=1)
    

Let’s turn those errors into a nice failure by creating an empty file called tennisGame.sh and make it executable. Now when we run our test, we don’t get an error:

./acceptanceTest.sh
    testItCanProvideAllTheScores
    1,9d0
    < John - Michael
    < John: 15 - Michael: 0
    < John: 30 - Michael: 0
    < John: 30 - Michael: 15
    < John: 40 - Michael: 15
    < John: 40 - Michael: 30
    < Deuce
    < John: Advantage
    < John: Winner
    ASSERT:Expected output differs.
    
    Ran 1 test.
    
    FAILED (failures=1)
    

Implementation with TDD

Create another file called unitTests.sh for our unit tests. We don’t want to run our script for each test; we only want to run the functions that we test. So, we will make tennisGame.sh run only the functions that will reside in functions.sh:

#! /usr/bin/env sh
    
    ### unitTest.sh ###
    
    source ../functions.sh
    
    function testItCanProvideFirstPlayersName () {
    	assertEquals 'John' `getFirstPlayerFrom 'John - Michael'`
    }
    
    ## Call and Run all Tests
    . "../shunit2-2.1.6/src/shunit2"
    

Our first test is simple. We attempt to retrieve the first player’s name when a line contains two names separated by a hyphen. This test will fail because we do not yet have a getFirstPlayerFrom function:

$ ./unitTest.sh
    testItCanProvideFirstPlayersName
    ./unitTest.sh: line 8: getFirstPlayerFrom: command not found
    shunit2:ERROR assertEquals() requires two or three arguments; 1 given
    shunit2:ERROR 1: John 2:  3:
    
    Ran 1 test.
    
    OK
    

The implementation for getFirstPlayerFromis very simple. It’s a regular expression that is pushed through the sed command:

### functions.sh ###
    
    function getFirstPlayerFrom () {
    	echo $1 | sed -e 's/-.*//'
    }
    

Now the test passes:

$ ./unitTest.sh
    testItCanProvideFirstPlayersName
    
    Ran 1 test.
    
    OK
    

Let’s write another test for the second player’s name:

### unitTest.sh ###
    
    [...]
    
    function testItCanProvideSecondPlayersName () {
    	assertEquals 'Michael' `getSecondPlayerFrom 'John - Michael'`
    }
    

The failure:

./unitTest.sh
    testItCanProvideFirstPlayersName
    testItCanProvideSecondPlayersName
    ASSERT:expected:<Michael> but was:<John>
    
    Ran 2 tests.
    
    FAILED (failures=1)
    

And now the function implementation to make it pass:

### functions.sh ###
    
    [...]
    
    function getSecondPlayerFrom () {
    	echo $1 | sed -e 's/.*-//'
    }

Now we have passing tests:

$ ./unitTest.sh
    testItCanProvideFirstPlayersName
    testItCanProvideSecondPlayersName
    
    Ran 2 tests.
    
    OK
    

Let’s Speed Things Up

Starting at this point, we will write a test and the implementation, and I will explain only what deserves to be mentioned.

Let’s test if we have a player with only one score. Added the following test:

function testItCanGetScoreForAPlayerWithOnlyOneWin () {
    	standings=$'John - Michael\nJohn'
    	assertEquals '1' `getScoreFor 'John' "$standings"`
    }
    

And the solution:

function getScoreFor () {
    	player=$1
    	standings=$2
    	totalMatches=$(echo "$standings" | grep $player | wc -l)
    	echo $(($totalMatches-1))
    }
    

We use some fancy-pants quoting to pass the newline sequence (\n) inside a string parameter. Then we use grep to find the lines that contain the player’s name and count them with wc. Finally, we subtract one from the result to counteract the presence of the first line (it contains only non-score related data).

Now we are at the refactoring phase of TDD.

I just realized that the code actually works for more than one point per player, and we can refactor our tests to reflect this. Change the above test function to the following:

function testItCanGetScoreForAPlayer () {
    	standings=$'John - Michael\nJohn\nMichael\nJohn'
    	assertEquals '2' `getScoreFor 'John' "$standings"`
    }
    

The tests still passes. Time to move on with our logic:

function testItCanOutputScoreAsInTennisForFirstPoint () {
    	assertEquals 'John: 15 - Michael: 0' "`displayScore 'John' 1 'Michael' 0`"
    }
    

And the implementation:

function displayScore () {
    	if [ "$2" -eq '1' ]; then
    		playerOneScore='15'
    	fi
    
    	echo "$1: $playerOneScore - $3: $4"
    }
    

I only check the second parameter. This looks like I’m cheating, but it is the simplest code to make the test pass. Writing another test forces us to add more logic, but what test should we write next?

There are two paths we can take. Testing if the second player recieves a point forces us to write another if statement, but we only have to add an else statement if we choose to test the first player’s second point. The latter implies an easier implementation, so let’s try that:

function testItCanOutputScoreAsInTennisForSecondPointFirstPlayer () {
    	assertEquals 'John: 30 - Michael: 0' "`displayScore 'John' 2 'Michael' 0`"
    }
    

And the implementation:

function displayScore () {
    	if [ "$2" -eq '1' ]; then
    		playerOneScore='15'
    	else
    		playerOneScore='30'
    	fi
    
    	echo "$1: $playerOneScore - $3: $4"
    }
    

This still looks cheating, but it works perfectly. Continuing on for the third point:

function testItCanOutputScoreAsInTennisForTHIRDPointFirstPlayer () {
    	assertEquals 'John: 40 - Michael: 0' "`displayScore 'John' 3 'Michael' 0`"
    }
    

The implementation:

function displayScore () {
    	if [ "$2" -eq '1' ]; then
    		playerOneScore='15'
    	elif [ "$2" -eq '2' ]; then
    		playerOneScore='30'
    	else
    		playerOneScore='40'
    	fi
    
    	echo "$1: $playerOneScore - $3: $4"
    }

This if-elif-else is starting to annoy me. I want to change it, but let’s first refactor our tests. We have three very similar tests; so let’s write them into a single test that makes three assertions:

function testItCanOutputScoreWhenFirstPlayerWinsFirst3Points () {
    	assertEquals 'John: 15 - Michael: 0' "`displayScore 'John' 1 'Michael' 0`"
    	assertEquals 'John: 30 - Michael: 0' "`displayScore 'John' 2 'Michael' 0`"
    	assertEquals 'John: 40 - Michael: 0' "`displayScore 'John' 3 'Michael' 0`"
    }
    

That’s better, and it still passes. Now, let’s create a similar test for the second player:

function testItCanOutputScoreWhenSecondPlayerWinsFirst3Points () {
    	assertEquals 'John: 0 - Michael: 15' "`displayScore 'John' 0 'Michael' 1`"
    	assertEquals 'John: 0 - Michael: 30' "`displayScore 'John' 0 'Michael' 2`"
    	assertEquals 'John: 0 - Michael: 40' "`displayScore 'John' 0 'Michael' 3`"
    }
    

Running this test results in interesting output:

testItCanOutputScoreWhenSecondPlayerWinsFirst3Points
    ASSERT:expected:<John: 0 - Michael: 15> but was:<John: 40 - Michael: 1>
    ASSERT:expected:<John: 0 - Michael: 30> but was:<John: 40 - Michael: 2>
    ASSERT:expected:<John: 0 - Michael: 40> but was:<John: 40 - Michael: 3>
    

Well that was unexpected. We knew that Michael would have incorrect scores. The surprise is John; he should have 0 not 40. Let’s fix that by first modifying the if-elif-else expression:

function displayScore () {
    	if [ "$2" -eq '1' ]; then
    		playerOneScore='15'
    	elif [ "$2" -eq '2' ]; then
    		playerOneScore='30'
    	elif [ "$2" -eq '3' ]; then
    		playerOneScore='40'
    	else
    		playerOneScore=$2
    	fi
    
    	echo "$1: $playerOneScore - $3: $4"
    }
    

The if-elif-else is now more complex, but we at least fixed the John’s scores:

testItCanOutputScoreWhenSecondPlayerWinsFirst3Points
    ASSERT:expected:<John: 0 - Michael: 15> but was:<John: 0 - Michael: 1>
    ASSERT:expected:<John: 0 - Michael: 30> but was:<John: 0 - Michael: 2>
    ASSERT:expected:<John: 0 - Michael: 40> but was:<John: 0 - Michael: 3>
    

Now let’s fix Michael:

function displayScore () {
    	echo "$1: `convertToTennisScore $2` - $3: `convertToTennisScore $4`"
    }
    
    function convertToTennisScore () {
    	if [ "$1" -eq '1' ]; then
    		playerOneScore='15'
    	elif [ "$1" -eq '2' ]; then
    		playerOneScore='30'
    	elif [ "$1" -eq '3' ]; then
    		playerOneScore='40'
    	else
    		playerOneScore=$1
    	fi
    
    	echo $playerOneScore;
    }
    

That worked well! Now it’s time to finally refactor that ugly if-elif-else expression:

function convertToTennisScore () {
    	declare -a scoreMap=('0' '15' '30' '40')
    	echo ${scoreMap[$1]};
    }
    

Value maps are wonderful! Let’s move on to the “Deuce” case:

function testItSayDeuceWhenPlayersAreEqualAndHaveEnoughPoinst () {
    	assertEquals 'Deuce' "`displayScore 'John' 3 'Michael' 3`"
    }
    

We check for “Deuce” when all players have at least a score of 40.

function displayScore () {
    	if [ $2 -gt 2 ] && [ $4 -gt 2 ] && [ $2 -eq $4 ]; then
    		echo "Deuce"
    	else
    		echo "$1: `convertToTennisScore $2` - $3: `convertToTennisScore $4`"
    	fi
    }
    

Now we test for the first player’s advantage:

function testItCanOutputAdvantageForFirstPlayer () {
    	assertEquals 'John: Advantage' "`displayScore 'John' 4 'Michael' 3`"
    }
    

And to make it pass:

function displayScore () {
    	if [ $2 -gt 2 ] && [ $4 -gt 2 ] && [ $2 -eq $4 ]; then
    		echo "Deuce"
    	elif [ $2 -gt 2 ] && [ $4 -gt 2 ] && [ $2 -gt $4 ]; then
    		echo "$1: Advantage"
    	else
    		echo "$1: `convertToTennisScore $2` - $3: `convertToTennisScore $4`"
    	fi
    }
    

There’s that ugly if-elif-else again, and we have a lot of duplication as well. All our tests pass, so let’s refactor:

function displayScore () {
    	if outOfRegularScore $2 $4 ; then
    		checkEquality $2 $4
    		checkFirstPlayerAdv $1 $2 $4
    	else
    		echo "$1: `convertToTennisScore $2` - $3: `convertToTennisScore $4`"
    	fi
    }
    
    function outOfRegularScore () {
    	[ $1 -gt 2 ] && [ $2 -gt 2 ]
    	return $?
    }
    
    function checkEquality () {
    	if [ $1 -eq $2 ]; then
    		echo "Deuce"
    	fi
    }
    
    function checkFirstPlayerAdv () {
    	if [ $2 -gt $3 ]; then
    		echo "$1: Advantage"
    	fi
    }
    

This’ll work for now. Let’s test the advantage for the second player:

function testItCanOutputAdvantageForSecondPlayer () {
    	assertEquals 'Michael: Advantage' "`displayScore 'John' 3 'Michael' 4`"
    }
    

And the code:

function displayScore () {
    	if outOfRegularScore $2 $4 ; then
    		checkEquality $2 $4
    		checkAdvantage $1 $2 $3 $4
    	else
    		echo "$1: `convertToTennisScore $2` - $3: `convertToTennisScore $4`"
    	fi
    }
    
    function checkAdvantage () {
    	if [ $2 -gt $4 ]; then
    		echo "$1: Advantage"
    	elif [ $4 -gt $2 ]; then
    		echo "$3: Advantage"
    	fi
    }
    

This works, but we have some duplication in the checkAdvantage function. Let’s simplify it and call it twice:

function displayScore () {
    	if outOfRegularScore $2 $4 ; then
    		checkEquality $2 $4
    		checkAdvantage $1 $2 $4
    		checkAdvantage $3 $4 $2
    	else
    		echo "$1: `convertToTennisScore $2` - $3: `convertToTennisScore $4`"
    	fi
    }
    
    function checkAdvantage () {
    	if [ $2 -gt $3 ]; then
    		echo "$1: Advantage"
    	fi
    }

This is actually better than our previous solution, and it reverts to the original implementation of this method. But we now we have another problem: I feel uncomfortable with the $1, $2, $3 and $4 variables. They need meaningful names:

function displayScore () {
    	firstPlayerName=$1; firstPlayerScore=$2
    	secondPlayerName=$3; secondPlayerScore=$4
    
    	if outOfRegularScore $firstPlayerScore $secondPlayerScore; then
    		checkEquality $firstPlayerScore $secondPlayerScore
    		checkAdvantageFor $firstPlayerName $firstPlayerScore $secondPlayerScore
    		checkAdvantageFor $secondPlayerName $secondPlayerScore $firstPlayerScore
    	else
    		echo "$1: `convertToTennisScore $2` - $3: `convertToTennisScore $4`"
    	fi
    }
    
    function checkAdvantageFor () {
    	if [ $2 -gt $3 ]; then
    		echo "$1: Advantage"
    	fi
    }
    

This makes our code longer, but it is significantly more expressive. I like it.

It’s time to find a winner:

function testItCanOutputWinnerForFirstPlayer () {
    	assertEquals 'John: Winner' "`displayScore 'John' 5 'Michael' 3`"
    }
    

We only have to modify the checkAdvantageFor function:

function checkAdvantageFor () {
    	if [ $2 -gt $3 ]; then
    		if [ `expr $2 - $3` -gt 1 ]; then
    			echo "$1: Winner"
    		else
    			echo "$1: Advantage"
    		fi
    	fi
    }
    

We are almost done! As our last step, we’ll write the code in tennisGame.sh to make the acceptance test pass. This will be fairly simple code:

#! /usr/bin/env sh
    
    ### tennisGame.sh ###
    
    . ./functions.sh
    
    playersLine=`head -n 1 $1`
    echo "$playersLine"
    firstPlayer=`getFirstPlayerFrom "$playersLine"`
    secondPlayer=`getSecondPlayerFrom "$playersLine"`
    
    wholeScoreFileContent=`cat $1`
    totalNoOfLines=`echo "$wholeScoreFileContent" | wc -l`
    for currentLine in `seq 2 $totalNoOfLines`
    	do
    	firstPlayerScore=$(getScoreFor $firstPlayer "`echo \"$wholeScoreFileContent\" | head -n $currentLine`")
    	secondPlayerScore=$(getScoreFor $secondPlayer "`echo \"$wholeScoreFileContent\" | head -n $currentLine`")
    	displayScore $firstPlayer $firstPlayerScore $secondPlayer $secondPlayerScore
    done
    

We read the first line to retrieve the names of the two players, and then we incrementally read the file to compute the score.

Final Thoughts

Shell scripts can easily grow from a few lines of code to a few hundred of lines. When this happens, maintenance becomes increasingly difficult. Using TDD and unit testing can greatly help to make your complex script easier to maintain—not to mention that it forces you to build your complex scripts in a more professional manner.

Her treatise, on the pathetic state of web education (both at the high school and college level) details how dated material is not only creating a disinterested generation of web designers and developers, but negatively impacting the future economic viability of whole countries.

Of sticking kids in front of PCs and expecting an entrepreneurial miracle, Debenham quotes a teacher as saying: “All we’re gearing our kids up for is a life in an office. No wonder there’s no stampede for that career path.”

At the end of her presentation, she proposes the need for a fix. How do you suggest we do a better job of educating future technologists?

Check out the full presentation, below:"