‎

1. How do we test?
2. Writing tests first?
3. Multiple test cases
4. Example 1
5. Example 2
6. Reminder

1. How do we test?

How do you know that your program actually works? Especially as it gets more complex?

Software development skills mean more than just writing code. It also includes knowing how to test your code, to prove that it is working as intended.

For the most basic tests, we investigate a portion of code and ask, "Given some inputs, what are the expected outputs?" and "If I run the program with these inputs, what are the actual outputs?", and finally, "Does my actual output match my expected output?"

Review 1. Given some input and expected output defined, a test would pass if…

○ The actual output is different from the expected output.
○ The actual output matches the expected output.
○ The program doesn't crash

Review 2. Let's say I've written a program that takes in two numbers as inputs and returns the sum as the output.

a. For our FIRST test case, let's say the inputs are 2 and 3. What would the expected output be?
b. For our SECOND test case, let's say the inputs are -2 and 5. What would the expected output be?

2. Writing tests first?

Notice that you don't actually need to know what is in the function before you write tests for it. Knowing what the program is supposed to do, you can figure out a set of inputs and outputs that it ought to have.

Often, it is very useful to write your test cases prior to actually writing any code. This helps you solidify what exactly he program is supposed to do. Plus, if you write your test cases afterwards, it is a bit like reading your own essay - your brain will skip over errors because it knows what you meant, and doesn't actually read the actual words (or code).

Review 3. Let's say you need to write a program that will update a person's account balance after they deposit some money.

a. What might be the input(s)? What might be the output?
- ○ INPUT / ○ OUTPUT: The current bank balance
- ○ INPUT / ○ OUTPUT: The bank balance after the deposit
- ○ INPUT / ○ OUTPUT: The amount to deposit
b. When writing test cases, if we have a current bank balance and a deposit amount, then…
- ○ We won't know what the new bank balance will be until we write the program.
- ○ We can calculate what the new balance would be by hand.
- ○ It is impossible to know anything; software is a dark and mysterious magic.
c. Given an initial balance of $100 and a deposit of $120, what would be the expected output after running this program?
d. Given an initial balance of $30 and a deposit of -$60, what would be the expected output after running the program?

3. Multiple test cases

It isn't good enough to write one single test case. Often, you will want to have enough test cases to check for as many possibilities as possible - though we can't write an infinite amount. So sometimes, it's best to just write tests for reasonable outcomes, including potential errors.

When we eventually write code to do our testing for us, we can have the program keep an "ear out" for an error happening - and, sometimes we want that error to occur. Such as if the user enters a negative deposit amount, we would want the program to notice and send an error code or error message. We could also write our tests to make sure the error occurs, rather than allowing the user to deposit (or withdraw) a "negative" amount of money!

Review 4. Our program needed a function that adds two numbers together and returns the result. Your coworker wrote one test case:

Test 1. Inputs: 2 and 2. Expected output: 4

Then they wrote this code:

#include <iostream>
using namespace std;

int main( int argumentCount, char* argumentList[] )
{
    cout << "The result is 4." << endl;

    return 0;
}

a. Your coworker says "well it passes the test!" - Do you trust your coworker?
- ○ Yes, absolutely. Clearly they know what they're doing.
- ○ No, their code doesn't have enough test coverage.
b. How could we actually make sure the function works properly?
- ○ By having at least one more test with different inputs, and a different output.
- ○ By writing another test with the same expected output of 4.

4. Example 1

Let's say your coworker Maryam is writing code for a new feature and you're writing the tests. You both have the requirements, so you can both work at the same time.

Review 5. The program takes in a list of grades (4.0 being 'A', 3.0 being 'B', 2.0 being 'C', 1.0 being 'D', and 0.0 being 'F') and calculates a grade point average. (Averages are calculated as the sum of all the grades divided by the amount of grades.)

a. For the first test case the inputs are: 4.0, 2.0, 3.5, 3.5. What would be the expected output?
b. For the second test case the inputs are: 2.4, 2.8, 3.2. What would be the expected output?
c. For the third test case, the inputs are: 3.0, 3.0, 3.0, 3.0. What would be the expected output?

5. Example 2

Now your coworker André is working on another part of the program, and you're writing the tests.

Review 6. The program takes in the price of a given textbook title, and an amount of that textbook to purchase, and returns the total cost of purchasing those textbooks.

a. For the first test case we want to order 5 copies of a book that costs $75.60. What is the expected output?
b. For the second test case we want to order 2 copies of a book that costs $49.82. What is the expected output?

6. Reminder

Takeaways:

A single test case consists of inputs and their expected output(s).
Running the program with the test's inputs will give us the actual output(s).
A test will pass if the actual output matches the expected output.
A test will fail if the actual output does not match the expected output.
Having multiple test cases help you verify that your code works properly.

Review 7. For now, we are writing our test cases on paper (or on the computer) and will be doing manual tests. Later on, we can write functions in our program to run those tests for us automatically.

○ Yay!
○ Wait, no, I WANT to manually test all the code I write. Clearly that's the most fun.