Maintainers.txt: Update email address

[mirror_edk2.git] / UnitTestFrameworkPkg / ReadMe.md

# Unit Test Framework Package\r
\r
## About\r
\r
This package adds a unit test framework capable of building tests for multiple contexts including\r
the UEFI shell environment and host-based environments. It allows for unit test development to focus\r
on the tests and leave error logging, result formatting, context persistance, and test running to the framework.\r
The unit test framework works well for low level unit tests as well as system level tests and\r
fits easily in automation frameworks.\r
\r
### UnitTestLib\r
\r
The main "framework" library. The core of the framework is the Framework object, which can have any number\r
of test cases and test suites registered with it. The Framework object is also what drives test execution.\r
\r
The Framework also provides helper macros and functions for checking test conditions and\r
reporting errors. Status and error info will be logged into the test context. There are a number\r
of Assert macros that make the unit test code friendly to view and easy to understand.\r
\r
Finally, the Framework also supports logging strings during the test execution. This data is logged\r
to the test context and will be available in the test reporting phase. This should be used for\r
logging test details and helpful messages to resolve test failures.\r
\r
### UnitTestPersistenceLib\r
\r
Persistence lib has the main job of saving and restoring test context to a storage medium so that for tests\r
that require exiting the active process and then resuming state can be maintained. This is critical\r
in supporting a system reboot in the middle of a test run.\r
\r
### UnitTestResultReportLib\r
\r
Library provides function to run at the end of a framework test run and handles formatting the report.\r
This is a common customization point and allows the unit test framework to fit its output reports into\r
other test infrastructure. In this package a simple library instances has been supplied to output test\r
results to the console as plain text.\r
\r
## Samples\r
\r
There is a sample unit test provided as both an example of how to write a unit test and leverage\r
many of the features of the framework. This sample can be found in the `Test/UnitTest/Sample/SampleUnitTest`\r
directory.\r
\r
The sample is provided in PEI, SMM, DXE, and UEFI App flavors. It also has a flavor for the HOST_APPLICATION\r
build type, which can be run on a host system without needing a target.\r
\r
## Usage\r
\r
This section is built a lot like a "Getting Started". We'll go through some of the components that are needed\r
when constructing a unit test and some of the decisions that are made by the test writer. We'll also describe\r
how to check for expected conditions in test cases and a bit of the logging characteristics.\r
\r
Most of these examples will refer to the SampleUnitTestUefiShell app found in this package.\r
\r
### Requirements - INF\r
\r
In our INF file, we'll need to bring in the `UnitTestLib` library. Conveniently, the interface\r
header for the `UnitTestLib` is located in `MdePkg`, so you shouldn't need to depend on any other\r
packages. As long as your DSC file knows where to find the lib implementation that you want to use,\r
you should be good to go.\r
\r
See this example in 'SampleUnitTestUefiShell.inf'...\r
\r
```\r
[Packages]\r
  MdePkg/MdePkg.dec\r
\r
[LibraryClasses]\r
  UefiApplicationEntryPoint\r
  BaseLib\r
  DebugLib\r
  UnitTestLib\r
  PrintLib\r
```\r
\r
Also, if you want you test to automatically be picked up by the Test Runner plugin, you will need\r
to make sure that the module `BASE_NAME` contains the word `Test`...\r
\r
```\r
[Defines]\r
  BASE_NAME      = SampleUnitTestUefiShell\r
```\r
\r
### Requirements - Code\r
\r
Not to state the obvious, but let's make sure we have the following include before getting too far along...\r
\r
```c\r
#include <Library/UnitTestLib.h>\r
```\r
\r
Now that we've got that squared away, let's look at our 'Main()'' routine (or DriverEntryPoint() or whatever).\r
\r
### Configuring the Framework\r
\r
Everything in the UnitTestPkg framework is built around an object called -- conveniently -- the Framework.\r
This Framework object will contain all the information about our test, the test suites and test cases associated\r
with it, the current location within the test pass, and any results that have been recorded so far.\r
\r
To get started with a test, we must first create a Framework instance. The function for this is\r
`InitUnitTestFramework`. It takes in `CHAR8` strings for the long name, short name, and test version.\r
The long name and version strings are just for user presentation and relatively flexible. The short name\r
will be used to name any cache files and/or test results, so should be a name that makes sense in that context.\r
These strings are copied internally to the Framework, so using stack-allocated or literal strings is fine.\r
\r
In the 'SampleUnitTestUefiShell' app, the module name is used as the short name, so the init looks like this.\r
\r
```c\r
DEBUG(( DEBUG_INFO, "%a v%a\n", UNIT_TEST_APP_NAME, UNIT_TEST_APP_VERSION ));\r
\r
//\r
// Start setting up the test framework for running the tests.\r
//\r
Status = InitUnitTestFramework( &Framework, UNIT_TEST_APP_NAME, gEfiCallerBaseName, UNIT_TEST_APP_VERSION );\r
```\r
\r
The `&Framework` returned here is the handle to the Framework. If it's successfully returned, we can start adding\r
test suites and test cases.\r
\r
Test suites exist purely to help organize test cases and to differentiate the results in reports. If you're writing\r
a small unit test, you can conceivably put all test cases into a single suite. However, if you end up with 20+ test\r
cases, it may be beneficial to organize them according to purpose. You _must_ have at least one test suite, even if\r
it's just a catch-all. The function to create a test suite is `CreateUnitTestSuite`. It takes in a handle to\r
the Framework object, a `CHAR8` string for the suite title and package name, and optional function pointers for\r
a setup function and a teardown function.\r
\r
The suite title is for user presentation. The package name is for xUnit type reporting and uses a '.'-separated\r
hierarchical format (see 'SampleUnitTestApp' for example). If provided, the setup and teardown functions will be\r
called once at the start of the suite (before _any_ tests have run) and once at the end of the suite (after _all_\r
tests have run), respectively. If either or both of these are unneeded, pass `NULL`. The function prototypes are\r
`UNIT_TEST_SUITE_SETUP` and `UNIT_TEST_SUITE_TEARDOWN`.\r
\r
Looking at 'SampleUnitTestUefiShell' app, you can see that the first test suite is created as below...\r
\r
```c\r
//\r
// Populate the SimpleMathTests Unit Test Suite.\r
//\r
Status = CreateUnitTestSuite( &SimpleMathTests, Fw, "Simple Math Tests", "Sample.Math", NULL, NULL );\r
```\r
\r
This test suite has no setup or teardown functions. The `&SimpleMathTests` returned here is a handle to the suite and\r
will be used when adding test cases.\r
\r
Great! Now we've finished some of the cruft, red tape, and busy work. We're ready to add some tests. Adding a test\r
to a test suite is accomplished with the -- you guessed it -- `AddTestCase` function. It takes in the suite handle;\r
a `CHAR8` string for the description and class name; a function pointer for the test case itself; additional, optional\r
function pointers for prerequisite check and cleanup routines; and and optional pointer to a context structure.\r
\r
Okay, that's a lot. Let's take it one piece at a time. The description and class name strings are very similar in\r
usage to the suite title and package name strings in the test suites. The former is for user presentation and the\r
latter is for xUnit parsing. The test case function pointer is what is actually executed as the "test" and the\r
prototype should be `UNIT_TEST_FUNCTION`. The last three parameters require a little bit more explaining.\r
\r
The prerequisite check function has a prototype of `UNIT_TEST_PREREQUISITE` and -- if provided -- will be called\r
immediately before the test case. If this function returns any error, the test case will not be run and will be\r
recorded as `UNIT_TEST_ERROR_PREREQUISITE_NOT_MET`. The cleanup function (prototype `UNIT_TEST_CLEANUP`) will be called\r
immediately after the test case to provide an opportunity to reset any global state that may have been changed in the\r
test case. In the event of a prerequisite failure, the cleanup function will also be skipped. If either of these\r
functions is not needed, pass `NULL`.\r
\r
The context pointer is entirely case-specific. It will be passed to the test case upon execution. One of the purposes\r
of the context pointer is to allow test case reuse with different input data. (Another use is for testing that wraps\r
around a system reboot, but that's beyond the scope of this guide.) The test case must know how to interpret the context\r
pointer, so it could be a simple value, or it could be a complex structure. If unneeded, pass `NULL`.\r
\r
In 'SampleUnitTestUefiShell' app, the first test case is added using the code below...\r
\r
```c\r
AddTestCase( SimpleMathTests, "Adding 1 to 1 should produce 2", "Addition", OnePlusOneShouldEqualTwo, NULL, NULL, NULL );\r
```\r
\r
This test case calls the function `OnePlusOneShouldEqualTwo` and has no prerequisite, cleanup, or context.\r
\r
Once all the suites and cases are added, it's time to run the Framework.\r
\r
```c\r
//\r
// Execute the tests.\r
//\r
Status = RunAllTestSuites( Framework );\r
```\r
\r
### A Simple Test Case\r
\r
We'll take a look at the below test case from 'SampleUnitTestApp'...\r
\r
```c\r
UNIT_TEST_STATUS\r
EFIAPI\r
OnePlusOneShouldEqualTwo (\r
  IN UNIT_TEST_FRAMEWORK_HANDLE  Framework,\r
  IN UNIT_TEST_CONTEXT           Context\r
  )\r
{\r
  UINTN     A, B, C;\r
\r
  A = 1;\r
  B = 1;\r
  C = A + B;\r
\r
  UT_ASSERT_EQUAL(C, 2);\r
  return UNIT_TEST_PASSED;\r
} // OnePlusOneShouldEqualTwo()\r
```\r
\r
The prototype for this function matches the `UNIT_TEST_FUNCTION` prototype. It takes in a handle to the Framework\r
itself and the context pointer. The context pointer could be cast and interpreted as anything within this test case,\r
which is why it's important to configure contexts carefully. The test case returns a value of `UNIT_TEST_STATUS`, which\r
will be recorded in the Framework and reported at the end of all suites.\r
\r
In this test case, the `UT_ASSERT_EQUAL` assertion is being used to establish that the business logic has functioned\r
correctly. There are several assertion macros, and you are encouraged to use one that matches as closely to your\r
intended test criterium as possible, because the logging is specific to the macro and more specific macros have more\r
detailed logs. When in doubt, there are always `UT_ASSERT_TRUE` and `UT_ASSERT_FALSE`. Assertion macros that fail their\r
test criterium will immediately return from the test case with `UNIT_TEST_ERROR_TEST_FAILED` and log an error string.\r
_Note_ that this early return can have implications for memory leakage.\r
\r
At the end, if all test criteria pass, you should return `UNIT_TEST_PASSED`.\r
\r
### More Complex Cases\r
\r
To write more advanced tests, first take a look at all the Assertion and Logging macros provided in the framework.\r
\r
Beyond that, if you're writing host-based tests and want to take a dependency on the UnitTestFrameworkPkg, you can\r
leverage the `cmocka.h` interface and write tests with all the features of the Cmocka framework.\r
\r
Documentation for Cmocka can be found here:\r
https://api.cmocka.org/\r
\r
## Development\r
\r
### Iterating on a Single Test\r
\r
When using the EDK2 Pytools for CI testing, the host-based unit tests will be built and run on any build that includes\r
the `NOOPT` build target.\r
\r
If you are trying to iterate on a single test, a convenient pattern is to build only that test module. For example,\r
the following command will build only the SafeIntLib host-based test from the MdePkg...\r
\r
```bash\r
stuart_ci_build -c .pytool/CISettings.py TOOL_CHAIN_TAG=VS2017 -p MdePkg -t NOOPT BUILDMODULE=MdePkg/Test/UnitTest/Library/BaseSafeIntLib/TestBaseSafeIntLib.inf\r
```\r
\r
### Hooking BaseLib\r
\r
Most unit test mocking can be performed by the functions provided in the UnitTestFramework libraries, but since\r
BaseLib is consumed by the Framework itself, it requires different techniques to substitute parts of the\r
functionality.\r
\r
To solve some of this, the UnitTestFramework consumes a special implementation of BaseLib for host-based tests.\r
This implementation contains a [hook table](https://github.com/tianocore/edk2/blob/e188ecc8b4aed8fdd26b731d43883861f5e5e7b4/MdePkg/Test/UnitTest/Include/Library/UnitTestHostBaseLib.h#L507)\r
that can be used to substitute test functionality for any of the BaseLib functions. By default, this implementation\r
will use the underlying BaseLib implementation, so the unit test writer only has to supply minimal code to test a\r
particular case.\r
\r
### Debugging the Framework Itself\r
\r
While most of the tests that are produced by the UnitTestFramework are easy to step through in a debugger, the Framework\r
itself consumes code (mostly Cmocka) that sets its own build flags. These flags cause parts of the Framework to not\r
export symbols and captures exceptions, and as such are harder to debug. We have provided a Stuart parameter to force\r
symbolic debugging to be enabled.\r
\r
You can run a build by adding the `BLD_*_UNIT_TESTING_DEBUG=TRUE` parameter to enable this build option.\r
\r
```bash\r
stuart_ci_build -c .pytool/CISettings.py TOOL_CHAIN_TAG=VS2019 -p MdePkg -t NOOPT BLD_*_UNIT_TESTING_DEBUG=TRUE\r
```\r
\r
## Building and Running Host-Based Tests\r
\r
The EDK2 CI infrastructure provides a convenient way to run all host-based tests -- in the the entire tree or just\r
selected packages -- and aggregate all the the reports, including highlighting any failures. This functionality is\r
provided through the Stuart build system (published by EDK2-PyTools) and the `NOOPT` build target.\r
\r
### Building Locally\r
\r
First, to make sure you're working with the latest PyTools, run the following command:\r
\r
```bash\r
# Would recommend to run this in a Python venv, but that's out of scope for this doc.\r
python -m pip install --upgrade -r ./pip-requirements.txt\r
```\r
\r
After that, the following commands will set up the build and run the host-based tests.\r
\r
```bash\r
# Setup repo for building\r
# stuart_setup -c ./.pytool/CISettings.py TOOL_CHAIN_TAG=<GCC5, VS2019, etc.>\r
stuart_setup -c ./.pytool/CISettings.py TOOL_CHAIN_TAG=VS2019\r
\r
# Update all binary dependencies\r
# stuart_update -c ./.pytool/CISettings.py TOOL_CHAIN_TAG=<GCC5, VS2019, etc.>\r
stuart_update -c ./.pytool/CISettings.py TOOL_CHAIN_TAG=VS2019\r
\r
# Build and run the tests\r
# stuart_ci_build -c ./.pytool/CISettings.py TOOL_CHAIN_TAG=<GCC5, VS2019, etc.> -t NOOPT [-p <Package Name>]\r
stuart_ci_build -c ./.pytool/CISettings.py TOOL_CHAIN_TAG=VS2019 -t NOOPT -p MdePkg\r
```\r
\r
### Evaluating the Results\r
\r
In your immediate output, any build failures will be highlighted. You can see these below as "WARNING" and "ERROR" messages.\r
\r
```text\r
(edk_env) PS C:\_uefi\edk2> stuart_ci_build -c .\.pytool\CISettings.py TOOL_CHAIN_TAG=VS2019 -t NOOPT -p MdePkg\r
\r
SECTION - Init SDE\r
SECTION - Loading Plugins\r
SECTION - Start Invocable Tool\r
SECTION - Getting Environment\r
SECTION - Loading plugins\r
SECTION - Building MdePkg Package\r
PROGRESS - --Running MdePkg: Host Unit Test Compiler Plugin NOOPT --\r
WARNING - Allowing Override for key TARGET_ARCH\r
PROGRESS - Start time: 2020-07-27 17:18:08.521672\r
PROGRESS - Setting up the Environment\r
PROGRESS - Running Pre Build\r
PROGRESS - Running Build NOOPT\r
PROGRESS - Running Post Build\r
SECTION - Run Host based Unit Tests\r
SUBSECTION - Testing for architecture: X64\r
WARNING - TestBaseSafeIntLibHost.exe Test Failed\r
WARNING -   Test SafeInt8ToUint8 - UT_ASSERT_EQUAL(0x5b:5b, Result:5c)\r
c:\_uefi\edk2\MdePkg\Test\UnitTest\Library\BaseSafeIntLib\TestBaseSafeIntLib.c:35: error: Failure!\r
ERROR - Plugin Failed: Host-Based Unit Test Runner returned 1\r
CRITICAL - Post Build failed\r
PROGRESS - End time: 2020-07-27 17:18:19.792313  Total time Elapsed: 0:00:11\r
ERROR - --->Test Failed: Host Unit Test Compiler Plugin NOOPT returned 1\r
ERROR - Overall Build Status: Error\r
PROGRESS - There were 1 failures out of 1 attempts\r
SECTION - Summary\r
ERROR - Error\r
\r
(edk_env) PS C:\_uefi\edk2>\r
```\r
\r
If a test fails, you can run it manually to get more details...\r
\r
```text\r
(edk_env) PS C:\_uefi\edk2> .\Build\MdePkg\HostTest\NOOPT_VS2019\X64\TestBaseSafeIntLibHost.exe\r
\r
Int Safe Lib Unit Test Application v0.1\r
---------------------------------------------------------\r
------------     RUNNING ALL TEST SUITES   --------------\r
---------------------------------------------------------\r
---------------------------------------------------------\r
RUNNING TEST SUITE: Int Safe Conversions Test Suite\r
---------------------------------------------------------\r
[==========] Running 71 test(s).\r
[ RUN      ] Test SafeInt8ToUint8\r
[  ERROR   ] --- UT_ASSERT_EQUAL(0x5b:5b, Result:5c)\r
[   LINE   ] --- c:\_uefi\edk2\MdePkg\Test\UnitTest\Library\BaseSafeIntLib\TestBaseSafeIntLib.c:35: error: Failure!\r
[  FAILED  ] Test SafeInt8ToUint8\r
[ RUN      ] Test SafeInt8ToUint16\r
[       OK ] Test SafeInt8ToUint16\r
[ RUN      ] Test SafeInt8ToUint32\r
[       OK ] Test SafeInt8ToUint32\r
[ RUN      ] Test SafeInt8ToUintn\r
[       OK ] Test SafeInt8ToUintn\r
...\r
```\r
\r
You can also, if you are so inclined, read the output from the exact instance of the test that was run during\r
`stuart_ci_build`. The ouput file can be found on a path that looks like:\r
\r
`Build/<Package>/HostTest/<Arch>/<TestName>.<TestSuiteName>.<Arch>.result.xml`\r
\r
A sample of this output looks like:\r
\r
```xml\r
<!--\r
  Excerpt taken from:\r
  Build\MdePkg\HostTest\NOOPT_VS2019\X64\TestBaseSafeIntLibHost.exe.Int Safe Conversions Test Suite.X64.result.xml\r
  -->\r
<?xml version="1.0" encoding="UTF-8" ?>\r
<testsuites>\r
  <testsuite name="Int Safe Conversions Test Suite" time="0.000" tests="71" failures="1" errors="0" skipped="0" >\r
    <testcase name="Test SafeInt8ToUint8" time="0.000" >\r
      <failure><![CDATA[UT_ASSERT_EQUAL(0x5c:5c, Result:5b)\r
c:\_uefi\MdePkg\Test\UnitTest\Library\BaseSafeIntLib\TestBaseSafeIntLib.c:35: error: Failure!]]></failure>\r
    </testcase>\r
    <testcase name="Test SafeInt8ToUint16" time="0.000" >\r
    </testcase>\r
    <testcase name="Test SafeInt8ToUint32" time="0.000" >\r
    </testcase>\r
    <testcase name="Test SafeInt8ToUintn" time="0.000" >\r
    </testcase>\r
```\r
\r
### XML Reporting Mode\r
\r
Since these applications are built using the CMocka framework, they can also use the following env variables to output\r
in a structured XML rather than text:\r
\r
```text\r
CMOCKA_MESSAGE_OUTPUT=xml\r
CMOCKA_XML_FILE=<absolute or relative path to output file>\r
```\r
\r
This mode is used by the test running plugin to aggregate the results for CI test status reporting in the web view.\r
\r
### Important Note\r
\r
This works on both Windows and Linux, but is currently limited to x64 architectures. Working on getting others, but we\r
also welcome contributions.\r
\r
## Known Limitations\r
\r
### PEI, DXE, SMM\r
\r
While sample tests have been provided for these execution environments, only cursory build validation\r
has been performed. Care has been taken while designing the frameworks to allow for execution during\r
boot phases, but only UEFI Shell and host-based tests have been thoroughly evaluated. Full support for\r
PEI, DXE, and SMM is forthcoming, but should be considered beta/staging for now.\r
\r
### Host-Based Support vs Other Tests\r
\r
The host-based test framework is powered internally by the Cmocka framework. As such, it has abilities\r
that the target-based tests don't (yet). It would be awesome if this meant that it was a super set of\r
the target-based tests, and it worked just like the target-based tests but with more features. Unfortunately,\r
this is not the case. While care has been taken to keep them as close a possible, there are a few known\r
inconsistencies that we're still ironing out. For example, the logging messages in the target-based tests\r
are cached internally and associated with the running test case. They can be saved later as part of the\r
reporting lib. This isn't currently possible with host-based. Only the assertion failures are logged.\r
\r
We will continue trying to make these as similar as possible.\r
\r
## Unit Test Location/Layout Rules\r
\r
Code/Test                                   | Location\r
---------                                   | --------\r
Host-Based Unit Tests for a Library/Protocol/PPI/GUID Interface   | If what's being tested is an interface (e.g. a library with a public header file, like DebugLib), the test should be scoped to the parent package.<br/>Example: `MdePkg/Test/UnitTest/[Library/Protocol/Ppi/Guid]/`<br/><br/>A real-world example of this is the BaseSafeIntLib test in MdePkg.<br/>`MdePkg/Test/UnitTest/Library/BaseSafeIntLib/TestBaseSafeIntLibHost.inf`\r
Host-Based Unit Tests for a Library/Driver (PEI/DXE/SMM) implementation   | If what's being tested is a specific implementation (e.g. BaseDebugLibSerialPort for DebugLib), the test should be scoped to the implementation directory itself, in a UnitTest subdirectory.<br/><br/>Module Example: `MdeModulePkg/Universal/EsrtFmpDxe/UnitTest/`<br/>Library Example: `MdePkg/Library/BaseMemoryLib/UnitTest/`\r
Host-Based Tests for a Functionality or Feature   | If you're writing a functional test that operates at the module level (i.e. if it's more than a single file or library), the test should be located in the package-level Tests directory under the HostFuncTest subdirectory.<br/>For example, if you were writing a test for the entire FMP Device Framework, you might put your test in:<br/>`FmpDevicePkg/Test/HostFuncTest/FmpDeviceFramework`<br/><br/>If the feature spans multiple packages, it's location should be determined by the package owners related to the feature.\r
Non-Host-Based (PEI/DXE/SMM/Shell) Tests for a Functionality or Feature   | Similar to Host-Based, if the feature is in one package, should be located in the `*Pkg/Test/[Shell/Dxe/Smm/Pei]Test` directory.<br/><br/>If the feature spans multiple packages, it's location should be determined by the package owners related to the feature.<br/><br/>USAGE EXAMPLES<br/>PEI Example: MP_SERVICE_PPI. Or check MTRR configuration in a notification function.<br/> SMM Example: a test in a protocol callback function. (It is different with the solution that SmmAgent+ShellApp)<br/>DXE Example: a test in a UEFI event call back to check SPI/SMRAM status. <br/> Shell Example: the SMM handler audit test has a shell-based app that interacts with an SMM handler to get information. The SMM paging audit test gathers information about both DXE and SMM. And the SMM paging functional test actually forces errors into SMM via a DXE driver.\r
\r
### Example Directory Tree\r
\r
```text\r
<PackageName>Pkg/\r
  ComponentY/\r
    ComponentY.inf\r
    ComponentY.c\r
    UnitTest/\r
      ComponentYHostUnitTest.inf      # Host-Based Test for Driver Module\r
      ComponentYUnitTest.c\r
\r
  Library/\r
    GeneralPurposeLibBase/\r
      ...\r
\r
    GeneralPurposeLibSerial/\r
      ...\r
\r
    SpecificLibDxe/\r
      SpecificLibDxe.c\r
      SpecificLibDxe.inf\r
      UnitTest/                      # Host-Based Test for Specific Library Implementation\r
        SpecificLibDxeHostUnitTest.c\r
        SpecificLibDxeHostUnitTest.inf\r
  Test/\r
    <Package>HostTest.dsc             # Host-Based Test Apps\r
    UnitTest/\r
      InterfaceX\r
        InterfaceXHostUnitTest.inf    # Host-Based App (should be in Test/<Package>HostTest.dsc)\r
        InterfaceXPeiUnitTest.inf     # PEIM Target-Based Test (if applicable)\r
        InterfaceXDxeUnitTest.inf     # DXE Target-Based Test (if applicable)\r
        InterfaceXSmmUnitTest.inf     # SMM Target-Based Test (if applicable)\r
        InterfaceXShellUnitTest.inf   # Shell App Target-Based Test (if applicable)\r
        InterfaceXUnitTest.c          # Test Logic\r
\r
      GeneralPurposeLib/              # Host-Based Test for any implementation of GeneralPurposeLib\r
        GeneralPurposeLibTest.c\r
        GeneralPurposeLibHostUnitTest.inf\r
\r
  <Package>Pkg.dsc          # Standard Modules and any Target-Based Test Apps (including in Test/)\r
\r
```\r
\r
### Future Locations in Consideration\r
\r
We don't know if these types will exist or be applicable yet, but if you write a support library or module that matches the following, please make sure they live in the correct place.\r
\r
Code/Test                                   | Location\r
---------                                   | --------\r
Host-Based Library Implementations                 | Host-Based Implementations of common libraries (eg. MemoryAllocationLibHost) should live in the same package that declares the library interface in its .DEC file in the `*Pkg/HostLibrary` directory. Should have 'Host' in the name.\r
Host-Based Mocks and Stubs  | Mock and Stub libraries should live in the `UefiTestFrameworkPkg/StubLibrary` with either 'Mock' or 'Stub' in the library name.\r
\r
### If still in doubt...\r
\r
Hop on GitHub and ask @corthon, @mdkinney, or @spbrogan. ;)\r
\r
## Copyright\r
\r
Copyright (c) Microsoft Corporation.\r
SPDX-License-Identifier: BSD-2-Clause-Patent\r