We'll write the remainder of this page as if it were describing stories for the music player. We'll use italics when we want to point out features of the framework. You might as well run the example now before you continue reading.
The music browser starts up looking at the whole library of songs. We specify the library (an advanced feature) so that we know what we are talking about in this document.
This is a the file that library reads. It is tab separated text. Try downloading it and looking at it with a spreadsheet. http:Release/Source/eg/music/Music.txt
We can pick songs and see details of our selection as we go.
|check||track||2 of 7|
ActionFixture interprets the words in the first column. The check action leads to a comparison of expected values from the table with actual values from the music program.
Once we've picked a song, we can play it. We can continue operating the Brower while music is playing.
The RealtimeActionFixture is a Fixture that adds actions having to do with realtime operation of the music player. We start by pressing play and then waiting for the status to show that it is playing. This music takes 2.5 seconds to start playing so it still says loading after our 2 second pause.
Warning: Don't confuse the pause action with the pause button. The pause action appears in column one where it is interpreted by the Simulator as if the user hesitates for a specified number of seconds. The pause button is a button on the music player part of the Browser screen. The press action activates the pause button which causes the currently playing song to stop temporarily.
Searching for Music
There are buttons on the browser to find more songs like the one we have picked.
We can find songs related in different ways. Each new way produces a (possibly) different list of songs. Show all restores the display to the initial conditions.
We left out the await actions so we are mashing buttons every second or so, faster than the searches complete. We're still getting the music we wanted because the search routines don't yet do a very good job of simulating being slow.
Yielding the display:
|Handy Man||James Taylor||JT||1977||3.30||7 of 12|
|Scarlet Woman||Weather Report||Mysterious Traveller||1974||5.72||6 of 7|
|Sailing To Philadelphia||James Taylor||October Rose||2000||5.47||3 of 3|
|Ananas||James Taylor||Hourglass||1997||5.73||5 of 13|
|Another Gray Morning||James Taylor||JT||1977||2.73||4 of 12|
The song Scarlet Woman is marked as missing because our search did not return this row. It really is missing, and rightfully so, because it isn't a James Taylor song.
The song Another Gray Morning is marked as missing because there is no song spelt that way in the result set. When left hand columns (the keys) disagree then we don't get a chance to compare the remaining columns.
The song Copperline wasn't expected in the result set so it is marked as surplus. The framework adds all the surplus songs to the table so that they can be seen. The show up with printing in light gray as a reminder that they are not a part of the original document.
This completes the MusicExample.
Now we consider some degenerate cases just to be sure that they work. Suppose we did not uniquely identify rows. We have two songs from JT. What happens when there are surplus (only one expected) ? When there are missing (three expelcted)?
|New Moon Shine||Pop|
|New Moon Shine||Pop|
We've run quite a few test. We'll call up one more Fixture that will add a summary to the end of our document.
This is our most complete standard example. You can run it against more than one fit implementation by choosing any one of these specialized RunScript.