<<  Back to Contents Page

Session 20 - Pseudocode & Test Plans

In This Session...

In this session we will be covering the following topics:-

• Review of last session

• Introduction

• Exercise 63: Specification for a "pairs" game

• Pseudocode

• Next session...

Review of Last Session

In the last session, we covered:-

• Indentation in functions

• Locals vs. Global variables - Scope Rules

• Exercise 59 - Well-indented function

• Locals vs. Global variables - Scope Rules

• Pass values using function parameters

• Pass values using global variables

• Passing parameters by reference

• Exercise 60 - Stepping through a reference parameter

• Exercise 61 - Changing the power function

• Exercise 62 - Passing strings to a function

• Passing strings and arrays

Introduction

In this session we will be taking a look at pseudo-code - a way of drafting out our programs without having to worry about the exact syntax (words and structure) that we would use in C to make the program work. Most people love using pseudo-code - it doesn't actually do anything, but it's a good way of getting what you want to do in a form that is a bit more methodical, but without being tetchy about how it looks!

We will also look at the test plan, and how we can take our specification how how a program should work, and design a plan that should tell us whether our program is working correctly - i.e. to specification - so that we can prove that our program works properly.  As you may imagine, this counts for a lot in the written exam.

Rather than wade through a load of dry theory on this one, we can get creative, which is a huge relief for most people after the complexities of the last few sessions (pointers and parameter passing - phew!)

So let's get cracking.  What program are we going to write today? 

Exercise 63: Specification for a "Pairs" game

Let's do a game - a somewhat simple game, but something we can play.

The card game we know as "pairs" involves the following steps:-

• Shuffle a deck of cards
• Put all of the cards in a random order out onto a table, face-down
• Turn two cards over at random
• If the two cards match in number (or are both Aces / Jacks / Queens / Kings), then you pick them up, and keep them.
• If there are more than two players, each player takes it in turn two turn two cards over
• As more cards are turned over, you start remembering the positions of cards, and try to match them to cards you have seen before - so it becomes a test of remembering the position of cards that have been turned over before.
• As more cards are paired, the odds of picking a pair increase, so the game gets faster-moving until...
• The last pair are turned over (which must match, unless you included the joker!) and the person with the most number of matching pairs wins.

Okay, so how should we simulate this with a computer program?

We need to define the scope of our program, which means we may come up with a good plan for how to implement the game, but restraints of time may means that we trim down our specs to something that is playable, but with few bells-and-whistles. I would recommend trimming things down to a minimum (but don't skimp on validation / good structure / proper use of variables etc.) in your feature list to make the program usable but not "clever" - this should give you time to complete the program in the time you are given to do the exam (6 hours).

We will discuss between us a list of features during the session, pare this down to the minimum, and use this as a template for designing a program. 

Pseudocode

Another way of working out how you are going to write a program, either instead of, or in conjunction with JSP, is to using something called pseudocode.  Most people like writing pseudocode, mostly because it doesn't actually have to execute correctly, and is by its very nature a rough draft.

Pseudocode does not have any strict rules about how to write it. Generally, it is a rough English-style version of a computer program. It tends to include words in common with most programming languages - such as if and loop and while and else (or maybe otherwise) etc. and logic tends to be in generalised form rather than exact logical rules. Here's a bit of pseudocode for our card game. If we have extra features, we may wish to add to it

1. Show a welcome screen and ask for the user's name
2. Store the 52 cards in an array
3. Swap two cards randomly in the array to simulate shuffling. Do this about 100 times.
4. Show all 52 cards back-down, perhaps numbered from 1-52 for easy selection. Show spaces where cards have been paired.
5. Ask the user to pick two cards out from the list
6. If the two cards picked have the same number or are jack/queen/king/ace, then zero them in the array to show they have been taken out, and then add 1 to number of pairs picked. Say "Well done Simon" or something like that for a bit of encouragement.
7. Add 1 to the number of pairing attempts made
8. if less than 52 divided by 2 (errr.. that's 26 pairs) pairs have been picked up, loop back to step 4.
9. End of game.

Of course, if you type this into your C compiler, then it won't work, because it isn't C. The trick is to turn it into C instructions. Having broken it down, we can do this a lot easier now. Generally, you need to go through the following steps to work out how to structure your program:-

• Go through the steps, and break them up into logical units - e.g. welcome screen, set up / shuffle array, main loop, show cards, get input for two cards, check input etc. etc. Each of these will probably be a function, called from the main() function. This is where your JSP diagram would come in handy, for creating the stubs of functions to outline which functions belong to which other functions - e.g. the main() function may contain the main_loop() function which may then call the show_cards() function followed by the get_input() function etc. etc.
• Work out any inputs / stored information and the likely type of data (e.g. character array (string), integer, arrays or single variables etc.) for each of these inputs. Give these an appropriate variable name.
• Work out if the variables are just being used for part of a program (probably a local variable inside a function) or throughout the program (probably a global variable, or should be passed as a parameter to functions).
• Put the variable definitions in the appropriate function stubs, and go through your pseudocode and make sure that the variable is going to be accessible from the functions where it will be needed. This will help you decide where you should have global variables, and where you will need to pass parameters into functions, and therefore the prototypes for each function.
• Fill in the C code to represent the steps you take in your pseudocode
• Test test test!! 

Functional Testing

We need to work out a plan as to how we would expect the program to behave if we put in specific input values. The idea is to test combinations of input values that are most likely to "break" our program. We are playing devil's advocate. Testing is often seen as a bit boring, but can be quite fun if you have any destructive tendencies, or of an ornery nature.

When constructing our test plan, we have to think about a number of things to come out with our list of things to test.  It is often useful to go through our JSP diagram, and pick a level at which we think we would can effectively test without missing anything important, or go through our pseudocode and pick out chunks of code an call them an 'action' which needs to be tested, because it does a specific task. Typically, this will be a single function if you have structured your program well.

If you find that your test plan is mainly testing specific functions, then top marks to you from the examiner - this will impress!

• Work out what the major functions / actions in the program are
• Determine if each of these has input - this may be from a pre-existing variable, from a parameter passed into a function, or from user input.
  If input should be within a specific range, then the boundary values should be tested - for example, if a number from 1-10 should be input, then test values 0,1, 10, and 11 to make sure the range is being tested correctly.
• Determine if each of these has output - this might be to a variable, or to the screen.
• Complete a matrix that lists each function, and a test for what we would expect outputs to be, given specific inputs.

Here is an example partial Test Plan:-

If you're wondering about the last test, here's the code for it:-

#include <stdio.h>
#include <conio.h>
#include <string.h>

void test_card();
void get_card( int card_no, char *res);

main()
{
  test_card();
  getch();
}

void test_card()
{
  int i;
  char str[4];

  printf("Card No: "); scanf( "%d", &i );
  get_card(i,str);
  printf("Card for %d is %s", i, str);
}

void get_card( int card_no, char *res)
{
  /* 13 cards per suite */
  switch (card_no % 13)
  {
    case(0): strcpy(res,"A"); break;
    case(1): strcpy(res,"2"); break;
    case(2): strcpy(res,"3"); break;
    case(3): strcpy(res,"4"); break;
    case(4): strcpy(res,"5"); break;
    case(5): strcpy(res,"6"); break;
    case(6): strcpy(res,"7"); break;
    case(7): strcpy(res,"8"); break;
    case(8): strcpy(res,"9"); break;
    case(9): strcpy(res,"10"); break;
    case(10): strcpy(res,"J"); break;
    case(11): strcpy(res,"Q"); break;
    case(12): strcpy(res,"K");

  }

  /* 4 suites */
  switch (card_no / 13)
  {
    case(0): strcat(res,"H"); break;
    case(1): strcat(res,"D"); break;
    case(2): strcat(res,"S"); break;
    case(3): strcat(res,"C"); break;
  }
}

If you put the test values in, you may get a better idea of how this works. The string is made up of two things - the value and the suite.

If the cards run from 0 to 12 for the first suite (hearts), you can see how the first case works. However, the diamonds suite then runs from 13 to 24 (13 being Ace of Diamonds, 14, 2 of Diamonds etc.) How do be reset the value back to 0 when we hit 13?  Remember our modulus (%) operator? This divides one number by another, and returns the remainder. So if we divide by 13 and get the remainder, then 1/13 give us 0 remainder 1, 12/13 gives us 0 remaidner 12, 13/13 gives us 1 remainder 0, 14/13 gives us 0 remainder 1 etc. etc. So this does the job we want - find the remainder, and this automatically resets the number back to 0 every 13 numbers in the series!

So how do we find the suite? Well, if we divide the suite number by 13, then every 13 cards, the integer value will increase by 1. As a switch statement can only take integer (or character) values, this gets converted automatically for us. So 0/13 gives 0, 12/13 gives 0 remainder 12 (i.e. 0 is the result here) but 13/13 gives 1 remainder 0 (i.e. 1 is the result here) - so this is the beginning of the diamonds suite. Great!  For further clarification, here's a list of all the values in a table:-

  A Microsoft-Word based test plan template is available from the contents page. You can use this and fill it in when you do your exam. Make sure you save it to your floppy disk so the examiner can see it too!

Code Stubs

Here's a sample set of code stubs for our pairs program:-

/* Define Prototypes */
void get_cards_out();
void play_again_loop();
void shuffle();
void game_loop();
void show_all_cards();
void turn_over_cards();
void compare_cards();

main()
{
  get_cards_out();
  play_again_loop();
}

void get_cards_out()
{

}

void play_again_loop()
{
  shuffle();
  game_loop();
}

void shuffle()
{

}

void game_loop()
{
  show_all_cards();
  turn_over_cards();
  compare_cards();
}

void show_all_cards()
{

}

void turn_over_cards()
{

}

void compare_cards()
{

}

This is taken from our JSP diagram. Now all that remains is to fill in the gaps!

In the Next Session...

In the next session we will be covering the following topics:-

• Implementing what we did today as a C program.

(c) Copyright 2003-4 Simon Huggins.   All Rights Reserved.
If you have any issues or questions regarding the content of this web site, please contact the author by clicking here.
Alternatively, you can leave a voice message on 00 44 (0)7050-618-297 or fax on 00 44 (0)7050-618-298
This Page was last updated: 29 January 2004 13:07