[SOLVED] Cop 4600 ex4: unit testing

Overview
When writing code, particularly for complex systems, it is imperative to continuously check that
your work is correct. Unit tests allow developers to write tests that demonstrate that output
matches specifications and mitigate the risk that changes in one area of the codebase cause
unintended consequences.
Structure
This exercise is broken into 3 parts:
1. Introduction to GoogleTest. You will build and install the unit testing framework.
2. White box testing. In white box testing, tests are written with full knowledge of the
implementation of the system; including knowledge of weak points and access to internal
data structures and functions.
3. Black box testing. In black box testing, tests are written with no knowledge of the
implementation of the system. Rather than testing internals, tests are written to ensure
correct outputs based on a specification.
Part 1: Introduction to GoogleTest
Installing GoogleTest
Before beginning the exercise, you will first install GoogleTest – a unit testing framework for
C++. GoogleTest is necessary to complete the remainder of the assignment.
You will begin by running the following sequence of commands:
sudo apt-get install cmake
git clone https://github.com/google/googletest.git -b v1.13.0
cd googletest # Main directory of the cloned repository.
mkdir build # Create a directory to hold the build output.
cd build
cmake .. -DBUILD_GMOCK=OFF # Generate makefile for GoogleTest
make
sudo make install # Install GoogleTest in /usr/local/
Exercise Files
The source files for this exercise can be obtained by running in the home directory
git clone https://github.com/utt-zachery/OS-Ex4.git
Anatomy of a Unit Test
A unit test is a function which verifies the output or value of other code (known as the subject
under test). This is achieved through an assertion. An assertion is a statement, which, if false,
indicates that the test has failed. Unit tests are compiled along with the subject under test into a
testing binary. The testing binary is then executed.
As an example, suppose the subject under test is the following function in Factorial.h:
int Factorial(int n);
Let us consider some simple unit tests for this integer function, written in
FactorialTests.cpp. Unit tests in GoogleTest begin with the TEST preprocessor macro.
#include “gtest/gtest.h”
#include “Factorial.h”
TEST(FactorialTest, HandlesZeroInput) {
int result = Factorial(0);
ASSERT_EQ(result, 1); //Assertion
}
Tests are organized into a “testing suite” (which simply denote groups of related tests). Here the
testing suite name is FactorialTest. When the testing binary is run, the output will be
organized by each testing suite.
Each test also contains a second field denoting the name of the test. Here the testing suite name
is HandlesZeroInput. Fields must be valid C++ function name variables (no underscores).
The body of the test contains some code followed with an assertion. The test will pass if all
assertions in the body pass.
You will not write a main entry point for your testing binary. Instead, you will link with the
GoogleTest library which includes one for you.
We’ve already built a Makefile for this test program. To run this sample test, simply navigate
to the “Part 1” folder and run the commands
make
./test.out
Results of running the testing binary
Part 2: White box Testing
In this part of the exercise, you will be writing tests for the following function, whose
implementation you are given:
//Returns true if a divides b
//Otherwise, returns false
bool isDivisible(int a, int b) {
return (b % a == 0);
}
A significant challenge when writing tests is deciding how many tests are needed. Since we can’t
test every integer, we will have to test a few values that represent the functionality of the whole
system.
For this exercise you will write the following tests inside DivisibilityTests.cpp:
1. A is positive, B is positive, and A does divide B. The function should return true.
2. A is positive, B is positive, and A does not divide B. The function should return false.
3. A is positive, B is zero. The function should return true.
4. A is negative, B is positive, and A does divide B. The function should return true.
Overall, there are 18 total tests that are needed to completely test this simple function! For this
assignment, simply write the 4 tests requested. All of your tests should pass.
We’ve already built a Makefile for this program. To run your tests, simply navigate to the “Part
2” folder and run the commands
make
./test.out
Part 3: Black box Testing
Often before development of a system begins, tests are first written which demonstrate the
specified functionality of the system. In this exercise, you will be writing black box tests for the
backend of a simple airplane trip booking system managing flights for a given date. You will not
be implementing this system.
The architecture of the system is as follows:
1. An Airport is an object consisting of a 3 letter airport code representing a unique
airport.
2. A Flight is an object that represents a scheduled flight from one Airport to another.
It describes a source Airport, a destination Airport, a departure time (represented as
an integer denoting the hour of takeoff in UTC), and a capacity (represented as an integer
denoting the remaining seats available for purchase). It is assumed that all flights depart
on the same day.
3. A Booking is an object that contains a list of Flight objects. It represents a single
flight option to get from a source Airport to a destination Airport. It contains a
single Flight object in the case of a direct flight; and two Flight objects in the case
of a connection.
You will write unit tests for each function provided in BackEnd.h. You will use the provided
interfaces to test the following specifications:
1. A query returns all available flight bookings from a source airport to a destination airport.
2. A query will not return any flight booking that includes a full flight.
3. When a flight booking is purchased, the capacities of all flights in the booking should be
decremented.
4. A booking either contains a single direct flight from the source airport to the destination
airport, or two flights: one from the source airport to a connection airport, and a second
from the connection airport to the destination airport. The second flight in a connection
must depart at least 2 hours after the first flight’s departure.
5. A query will only return bookings with connections when there are no direct flights from
the source airport to the destination airport.
6. If multiple flight bookings are returned by the query, bookings should be ordered by
departure time, with the earliest flight first. In the case that a booking is a connection, it is
ordered solely based on the departure time of the earlier flight.
Note: The “subject under test” (SUT) are the functions in BackEnd.h. Assume that the all the
other classes are correct. You may freely use any function you would like in any of the classes
provided (including any constructors).
Your unit tests will be written in a file called UnitTests.cpp (located in “Part 3” in the
exercise source repository cloned in Part 1) which will contain your test definitions.
Your unit tests should fully test the specifications of the system. In particular, your unit tests will
need to
(1) Create Airport instances
(2) Create Flight instances
(3) Using the objects created in (1) and (2), demonstrate that the booking system produces all
correct Booking objects sorted in order when using flightBookingQuery
(4) Demonstrate that the booking system correctly processes Booking objects when using
purchaseBooking, and that subsequent flightBookingQuery calls adhere to the
specification.
We have provided a dummy implementation of BackEnd.cpp so you can verify that your tests
properly compile, link, and execute. Of course, many of your tests should fail since the dummy
version of BackEnd.cpp does not adhere to the specification.
We will grade the quality of your tests by recompiling your tests on different implementations of
BackEnd.cpp! Some of these implementations are correct; some are incorrect. Your unit tests
should all pass on the proper implementation; and at least one test should fail on the incorrect
implementations. You must write enough unit tests to completely cover all items of the
specification. When writing your unit tests, you must not assume anything that is not stated
in the specification.
You may only modify UnitTests.cpp. Assume that all inputs to the functions in
BackEnd.cpp are valid (i.e. do not test passing invalid strings or nullptr). Your tests must
be fully automated (must run with no command line args/user input).
We’ve already built a Makefile for this program. To run your tests, simply navigate to the “Part
3” folder and run the commands
make
./test.out
Submissions
You will submit the following files for this assignment:
Part 1: Nothing
Part 2:
• A screenshot showing the execution of your tests (Part2.png)
• The source file containing your unit tests (DivisibilityTests.cpp)
Part 3:
• The source file containing your unit tests (UnitTests.cpp)