This PR makes many changes to the layout and build process for the unit tests. It also increases the code coverage significantly.
Change 1 - Create basic unit tests for aa-caller
Previously the aa-caller executable did not have any unit tests. This fixes that by adding a few basic tests to the executable. Some changes needed to be made to the build process for both aa-caller and the unit tests to allow this.
Change 2 - Access private variables from the unit tests
Previously the unit tests did not have access to private variables and functions for the classes they were testing. This can make it much harder to write adequate tests, because oftentimes we want to see how functions modify individual widgets in the GUI.
It is possible to overcome this by using the FRIEND_TEST macro inside the header for the source code of the tested class. However, this would require including the gtest library to be included in the main executable. Naturally, I wanted to avoid this for the main build.
My first solution, was to build the project differently between the Release build type or the Debug build type. If the project was built in Release mode, no tests would be generated. Alternatively, if the project was built in Debug mode, a preprocessor variable titled "TESTS_ENABLED" would be defined, which I would use to conditionally include the gtest libraries and the FRIEND_TEST macro.
This seemed like a fine enough solution, but it didn't really satisfy me. I did not like having to change the build type of the project just to enable unit tests, and it was causing a few minor issues with the code coverage generation.
The current solution is to re-compile the code with different flags when building the unit tests. The code under src/ will be compiled once when make is called. The default target will not build the unit tests. Optionally afterwards, the user can build the unit tests by calling make test, which will rebuild the code under src/ with the necessary flags for the testing and code coverage analysis. The current solution still uses the "TESTS_ENABLED" definition and FRIEND_TEST macro, but the project is built in a different way.
Many of these changes were actually implemented and merged in PR #35
Change 3 - Create tests for Profiles tab
Somehow, I never got around to writing tests for the Profiles tab. This PR also adds tests for that. This task was relatively easy, now that I can access private variables and widgets from the unit tests.
Change 4 - Rewrite tests for many classes
Now that I can access private variables from inside unit tests, I was able to simplify the tests for many classes by utilizing the extra flexibility.
Some of the classes I modified were:
DispatcherMiddleman
CommandCaller
BlockingQueue
Each of the adapter classes
Change 5 - Fix CTD issue
Previously, there was an issue when constructing both the Help pane and the FileChooser page. Unbeknownst to me, the GTK::Builder widgets were being constructed using the create_from_file(...) function, instead of the correct create_from_resource(...) function. This made it so that the main binary would crash, unless it was executed in the directory in was compiled in. I was able to fix the change and include it in this PR.
We should include tests to check for this type of issue in the future.
Description
This PR makes many changes to the layout and build process for the unit tests. It also increases the code coverage significantly.
Change 1 - Create basic unit tests for aa-caller
Previously the aa-caller executable did not have any unit tests. This fixes that by adding a few basic tests to the executable. Some changes needed to be made to the build process for both aa-caller and the unit tests to allow this.
Change 2 - Access private variables from the unit tests
Previously the unit tests did not have access to private variables and functions for the classes they were testing. This can make it much harder to write adequate tests, because oftentimes we want to see how functions modify individual widgets in the GUI.
It is possible to overcome this by using the
FRIEND_TESTmacro inside the header for the source code of the tested class. However, this would require including the gtest library to be included in the main executable. Naturally, I wanted to avoid this for the main build.My first solution, was to build the project differently between the Release build type or the Debug build type. If the project was built in Release mode, no tests would be generated. Alternatively, if the project was built in Debug mode, a preprocessor variable titled "TESTS_ENABLED" would be defined, which I would use to conditionally include the gtest libraries and the
FRIEND_TESTmacro.This seemed like a fine enough solution, but it didn't really satisfy me. I did not like having to change the build type of the project just to enable unit tests, and it was causing a few minor issues with the code coverage generation.
The current solution is to re-compile the code with different flags when building the unit tests. The code under
src/will be compiled once whenmakeis called. The default target will not build the unit tests. Optionally afterwards, the user can build the unit tests by callingmake test, which will rebuild the code undersrc/with the necessary flags for the testing and code coverage analysis. The current solution still uses the "TESTS_ENABLED" definition andFRIEND_TESTmacro, but the project is built in a different way.Many of these changes were actually implemented and merged in PR #35
Change 3 - Create tests for Profiles tab
Somehow, I never got around to writing tests for the Profiles tab. This PR also adds tests for that. This task was relatively easy, now that I can access private variables and widgets from the unit tests.
Change 4 - Rewrite tests for many classes
Now that I can access private variables from inside unit tests, I was able to simplify the tests for many classes by utilizing the extra flexibility.
Some of the classes I modified were:
Change 5 - Fix CTD issue
Previously, there was an issue when constructing both the Help pane and the FileChooser page. Unbeknownst to me, the
GTK::Builderwidgets were being constructed using thecreate_from_file(...)function, instead of the correctcreate_from_resource(...)function. This made it so that the main binary would crash, unless it was executed in the directory in was compiled in. I was able to fix the change and include it in this PR.We should include tests to check for this type of issue in the future.