Modify example in the primer to match Testing FAQ.
The CtorVsSetUp section of the FAQ says that constructors and destructors should be preferred over SetUp() and TearDown(), because they will automatically chain up to the fixture's base class, whereas for methods the user must remember to add the chaining manually. PiperOrigin-RevId: 624273474 Change-Id: Ida41aae193d417eaf996587c7ae1a0099a8cab32
This commit is contained in:
parent
b1a777f319
commit
5197b1a8e6
@ -273,14 +273,14 @@ First, define a fixture class. By convention, you should give it the name
|
|||||||
```c++
|
```c++
|
||||||
class QueueTest : public testing::Test {
|
class QueueTest : public testing::Test {
|
||||||
protected:
|
protected:
|
||||||
void SetUp() override {
|
QueueTest() {
|
||||||
// q0_ remains empty
|
// q0_ remains empty
|
||||||
q1_.Enqueue(1);
|
q1_.Enqueue(1);
|
||||||
q2_.Enqueue(2);
|
q2_.Enqueue(2);
|
||||||
q2_.Enqueue(3);
|
q2_.Enqueue(3);
|
||||||
}
|
}
|
||||||
|
|
||||||
// void TearDown() override {}
|
// ~QueueTest() override = default;
|
||||||
|
|
||||||
Queue<int> q0_;
|
Queue<int> q0_;
|
||||||
Queue<int> q1_;
|
Queue<int> q1_;
|
||||||
@ -288,8 +288,9 @@ class QueueTest : public testing::Test {
|
|||||||
};
|
};
|
||||||
```
|
```
|
||||||
|
|
||||||
In this case, `TearDown()` is not needed since we don't have to clean up after
|
In this case, we don't need to define a destructor or a `TearDown()` method,
|
||||||
each test, other than what's already done by the destructor.
|
because the implicit destructor generated by the compiler will perform all of
|
||||||
|
the necessary cleanup.
|
||||||
|
|
||||||
Now we'll write tests using `TEST_F()` and this fixture.
|
Now we'll write tests using `TEST_F()` and this fixture.
|
||||||
|
|
||||||
@ -326,11 +327,9 @@ would lead to a segfault when `n` is `NULL`.
|
|||||||
When these tests run, the following happens:
|
When these tests run, the following happens:
|
||||||
|
|
||||||
1. GoogleTest constructs a `QueueTest` object (let's call it `t1`).
|
1. GoogleTest constructs a `QueueTest` object (let's call it `t1`).
|
||||||
2. `t1.SetUp()` initializes `t1`.
|
2. The first test (`IsEmptyInitially`) runs on `t1`.
|
||||||
3. The first test (`IsEmptyInitially`) runs on `t1`.
|
3. `t1` is destructed.
|
||||||
4. `t1.TearDown()` cleans up after the test finishes.
|
4. The above steps are repeated on another `QueueTest` object, this time
|
||||||
5. `t1` is destructed.
|
|
||||||
6. The above steps are repeated on another `QueueTest` object, this time
|
|
||||||
running the `DequeueWorks` test.
|
running the `DequeueWorks` test.
|
||||||
|
|
||||||
**Availability**: Linux, Windows, Mac.
|
**Availability**: Linux, Windows, Mac.
|
||||||
|
Loading…
Reference in New Issue
Block a user