Project #2

Purpose:

One focus area for this course is understanding how to structure and implement big software systems. By big we mean systems that may consist of hundreds or even thousands of packages¹ and perhaps several million lines of code. We won't be building anything quite that large, but our projects may be considerably bigger than anything you've worked on before. In order to successfully implement big systems we need to partition code into relatively small parts and thoroughly test each of the parts before inserting them into the software baseline². As new parts are added to the baseline and as we make changes to fix latent errors or performance problems we will re-run test sequences for those parts and, perhaps, for the entire baseline. Managing that process efficiently requires effective tools for code analysis as well as testing. How we do that code analysis is illustrated by the projects for this year. The projects this Fall focus on building software testing tools. We will emphasize C++ code but want our tools to be easily extendable to other similar languages like C# and Java. You will find it useful to look at the SW Testing blog for a brief introduction to production testing.

In this second project we will build and test the core functionality for multi-user testing. Our final project will build a TestHarness server that creates child processes for each test request it receives. The test request causes execution of a container of tests, like the one we built in Project #1, in its own process. This project will build something close to the child process created by the TestHarness server, e.g., the Remote TestHarness will spawn multiple processes that run our Project #2 code. Project #3 will build a message-passing communication system, and use it to support interprocess communication between the host of a process pool and each child process in the pool. We will discuss a lot more about that when we get to Project #3. Project #4 will then uses those facilities and the code from this project to build a multi-user TestHarness. Most of our effort on that project will be devoted to building an effective graphical user interface.

In this project, we will develop facilities for:

Loading dynamic link test libraries:
Each test library is implemented as a dynamic link library. The library contains a test driver that implements an ITest interface, has references to the code to be tested, and also to the single-user TestHarness we built in Project #1 and a Logger we build in this project.
Executing tests:
When the project Executive loads the test library, it executes the library's test sequence using a bool test() method declared in the ITest interface.
Reporting results:
The test driver uses its reference to the logging facility and uses it to present test results on the project console, including, but not limited to, the test status returned by test().

Requirements:

Your TestHarness Core Solution:

Shall use Visual Studio 2017 and its C++ Windows Console Projects, as provided in the ECS computer labs.
Shall use the standard streams libraries for all I/O and operators new and delete for memory management.
(3) Shall provide an Executive package that loads all the test libraries from a specified directory, and executes the TestRequest from each library after loading.
(2) Shall also provide Loader, Executor, and Logger packages.
(3) The Loader package shall support finding and loading all the test libraries at a path specified by the Executive.
(4) The Executor package shall support executing all the tests in each TestRequest³.
(3) The Logger package shall support sending messages constructed by each test driver to standard C++ streams. That could be the process console, a file, or a std::ostringstream. It shall support sending each message to multiple streams that have been registered with the logger.
(5) The TestHarness Core shall own the logger and provide a reference to the testdriver of a TestRequest, on demand. Each requester shall get its own instance of the logger. The TestHarness shall be responsible for controlling the lifetime of each logger instance it creates.
(5) Shall include an automated unit test suite that exercises all of the special cases that seem appropriate for these packages⁴.

In C++, a package consists of two source code files, a header (*.h) and an implementation file (*.cpp) that contain:
- prologue, providing a name, brief descriptive phrase, author information, and environment information
- description of the package's responsiblities and required files
- maintenance history
- class declaration and definitions
- a main function, guarded by #ifdef and #endif declarations, that implements construction tests for all the defined code
A software baseline is the set of all code considered to be part of the current system, excluding experimental code that individual developers are working on.
A TestRequest is implemented with a single-user TestHarness, as implemented in Project #1. Each test library contains one TestRequest.
The unit test suite must demonstrate that your implementation meets all requirements for this project that you have implemented. You will not receive credit for any functional requirements that you do not demonstrate in this test, even if you have implemented them.

Project #2 - Multi-User Test Harness Core

Purpose:

Requirements:

What you need to know: