@@ -4,15 +4,15 @@ Build and Test status: 
8
8
framework for commercial use, please note
9
9
"Matthew Eshleman" or "Cove Mountain Software" in the referral
10
10
field when acquiring a commercial license from Quantum Leaps. Referrals
11
- encourage and support this effort . Thank you!
11
+ encourage and support efforts like this . Thank you!
12
12
13
13
# Introduction
14
14
15
- The ` cpputest-for-qpcpp ` project enables CppUTest for the
15
+ The ` cpputest-for-qpcpp ` library project enables CppUTest for the
16
16
QP/C++ Real-Time Embedded Framework. This project provides for the
17
17
following capabilities:
18
18
@@ -46,22 +46,20 @@ Benefits of this approach to unit testing active objects include:
46
46
47
47
# Environment
48
48
49
- This project was developed and proven in Ubuntu 20.04. In theory any
49
+ This project was developed and proven in Ubuntu 20.04 and 22.04 . In theory any
50
50
build or host operating system environment supported by CppUTest will
51
51
be compatible with this code.
52
52
53
53
## Prerequisites
54
54
55
- * qpcpp (pulled in as a git submodule)
56
- * After cloning this repository, do not forget to:
57
- * ` git submodule init `
58
- * ` git submodule update --recursive `
59
- * NOTE: As of January 2023, qpcpp is also using submodules. Developers
60
- may need to perform similar steps within the externals/qpcpp/
61
- directory as well.
62
- * CppUTest (version 3.8-7, the default in Ubuntu 20.04)
63
55
* CMake and associated build tools were used to develop
64
56
and prove out this project.
57
+ * QP/C++
58
+ * You can override the QP/C++ to another directory with your project's exact QP/C++ source code.
59
+ Define the cmake variable CMS_QPCPP_TOP_DIR before including the internal CMakeLists.txt.
60
+ * or:
61
+ * Do not define CMS_QPCPP_TOP_DIR, and the internal cmake will fetch the appropriate QP/C++ repo.
62
+ * CppUTest (version 3.8-7 or version 4.0) (3.8 is the default in Ubuntu 20.04 while 4.0 is the default in Ubuntu 22.04)
65
63
* This project requires support for C++14.
66
64
67
65
## Continuous Integration
@@ -131,13 +129,14 @@ behavior, using the exact same interfaces the active object would use
131
129
in the production target. CppUTest provides for the mocking capabilities to
132
130
ensure that the active object under test is calling the expected APIs.
133
131
134
- Within this project, please see the tests for ` cms::HwLockCtrl::Service ` which
132
+ Within the associated examples project, please see the tests for ` examples/hwLockCtrlService ` which
135
133
provides examples of:
136
134
* Testing for reaction to a published event, where the reaction is observed
137
135
through a CppUTest ` mock() ` .
138
136
* Testing to ensure the active object published an expected event. This project
139
137
provides for functionality (` cms::test::PublishedEventRecorder ` ) to record all
140
- events published during a test. The recorded events can be retrieved and verified by the test.
138
+ events published during a test. The recorded events can be retrieved and verified
139
+ by the test.
141
140
* Testing of time related behavior. This project provides for the ability to
142
141
` MoveTimeForward ` within a test.
143
142
* Direct POST of events and testing of direct POST responses. See
@@ -172,16 +171,16 @@ provides for convenience and helper methods such as:
172
171
events published into the framework. Useful when a test expects an
173
172
active object under test to publish an event.
174
173
175
-
176
174
## The basic active object test pattern
177
175
178
176
To create tests for an active object, the following outline is considered:
179
177
180
178
1 . Implement the ` setup() ` handler for the test. Initialize the QF framework as
181
179
desired using ` cms::test::qf_ctrl::Setup(...) ` .
182
- 2 . Instantiate the active object under test.
183
- 3 . ` start ` the active object under test.
184
- 4 . Begin writing a test.
180
+ 2 . Instantiate or otherwise initialize the active object under test.
181
+ 3 . ` start ` the active object under test, perhaps as part of the ` setup `
182
+ or as a separate step.
183
+ 4 . Prep a single test.
185
184
5 . Prepare a CppUTest mock() or other resources as needed for the test.
186
185
6 . Stimulate the unit under test as appropriate. For example, publish an
187
186
event into the framework that the active object is expected to be subscribed to
@@ -196,7 +195,7 @@ examples at: `examples/hwLockCtrlService/test/hwLockCtrlServiceTests.cpp` to
196
195
learn more.
197
196
198
197
Other tips:
199
- * Avoid internal state knowledge as much as is reasonable . This allows for internal
198
+ * Avoid internal state knowledge as much as possible . This allows for internal
200
199
state machine refactoring without impacting the tests.
201
200
* Follow best practices in your test code, especially follow the DRY principle.
202
201
0 commit comments