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:
Krzysztof Kosiński 2024-04-12 13:18:22 -07:00 committed by Copybara-Service
parent b1a777f319
commit 5197b1a8e6

View File

@ -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.