1
// Copyright 2005, Google Inc.
2
// All rights reserved.
4
// Redistribution and use in source and binary forms, with or without
5
// modification, are permitted provided that the following conditions are
8
// * Redistributions of source code must retain the above copyright
9
// notice, this list of conditions and the following disclaimer.
10
// * Redistributions in binary form must reproduce the above
11
// copyright notice, this list of conditions and the following disclaimer
12
// in the documentation and/or other materials provided with the
14
// * Neither the name of Google Inc. nor the names of its
15
// contributors may be used to endorse or promote products derived from
16
// this software without specific prior written permission.
18
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
19
// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
20
// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
21
// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
22
// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
23
// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
24
// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
25
// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
26
// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
27
// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
28
// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
30
// Author: wan@google.com (Zhanyong Wan)
32
// This sample teaches how to reuse a test fixture in multiple test
33
// cases by deriving sub-fixtures from it.
35
// When you define a test fixture, you specify the name of the test
36
// case that will use this fixture. Therefore, a test fixture can
37
// be used by only one test case.
39
// Sometimes, more than one test cases may want to use the same or
40
// slightly different test fixtures. For example, you may want to
41
// make sure that all tests for a GUI library don't leak important
42
// system resources like fonts and brushes. In Google Test, you do
43
// this by putting the shared logic in a super (as in "super class")
44
// test fixture, and then have each test case use a fixture derived
45
// from this super fixture.
49
#include "sample3-inl.h"
50
#include <gtest/gtest.h>
53
// In this sample, we want to ensure that every test finishes within
54
// ~5 seconds. If a test takes longer to run, we consider it a
57
// We put the code for timing a test in a test fixture called
58
// "QuickTest". QuickTest is intended to be the super fixture that
59
// other fixtures derive from, therefore there is no test case with
60
// the name "QuickTest". This is OK.
62
// Later, we will derive multiple test fixtures from QuickTest.
63
class QuickTest : public testing::Test {
65
// Remember that SetUp() is run immediately before a test starts.
66
// This is a good place to record the start time.
67
virtual void SetUp() {
68
start_time_ = time(NULL);
71
// TearDown() is invoked immediately after a test finishes. Here we
72
// check if the test was too slow.
73
virtual void TearDown() {
74
// Gets the time when the test finishes
75
const time_t end_time = time(NULL);
77
// Asserts that the test took no more than ~5 seconds. Did you
78
// know that you can use assertions in SetUp() and TearDown() as
80
EXPECT_TRUE(end_time - start_time_ <= 5) << "The test took too long.";
83
// The UTC time (in seconds) when the test starts
88
// We derive a fixture named IntegerFunctionTest from the QuickTest
89
// fixture. All tests using this fixture will be automatically
90
// required to be quick.
91
class IntegerFunctionTest : public QuickTest {
92
// We don't need any more logic than already in the QuickTest fixture.
93
// Therefore the body is empty.
97
// Now we can write tests in the IntegerFunctionTest test case.
100
TEST_F(IntegerFunctionTest, Factorial) {
101
// Tests factorial of negative numbers.
102
EXPECT_EQ(1, Factorial(-5));
103
EXPECT_EQ(1, Factorial(-1));
104
EXPECT_TRUE(Factorial(-10) > 0);
106
// Tests factorial of 0.
107
EXPECT_EQ(1, Factorial(0));
109
// Tests factorial of positive numbers.
110
EXPECT_EQ(1, Factorial(1));
111
EXPECT_EQ(2, Factorial(2));
112
EXPECT_EQ(6, Factorial(3));
113
EXPECT_EQ(40320, Factorial(8));
118
TEST_F(IntegerFunctionTest, IsPrime) {
119
// Tests negative input.
120
EXPECT_TRUE(!IsPrime(-1));
121
EXPECT_TRUE(!IsPrime(-2));
122
EXPECT_TRUE(!IsPrime(INT_MIN));
124
// Tests some trivial cases.
125
EXPECT_TRUE(!IsPrime(0));
126
EXPECT_TRUE(!IsPrime(1));
127
EXPECT_TRUE(IsPrime(2));
128
EXPECT_TRUE(IsPrime(3));
130
// Tests positive input.
131
EXPECT_TRUE(!IsPrime(4));
132
EXPECT_TRUE(IsPrime(5));
133
EXPECT_TRUE(!IsPrime(6));
134
EXPECT_TRUE(IsPrime(23));
138
// The next test case (named "QueueTest") also needs to be quick, so
139
// we derive another fixture from QuickTest.
141
// The QueueTest test fixture has some logic and shared objects in
142
// addition to what's in QuickTest already. We define the additional
143
// stuff inside the body of the test fixture, as usual.
144
class QueueTest : public QuickTest {
146
virtual void SetUp() {
147
// First, we need to set up the super fixture (QuickTest).
150
// Second, some additional setup for this fixture.
156
// By default, TearDown() inherits the behavior of
157
// QuickTest::TearDown(). As we have no additional cleaning work
158
// for QueueTest, we omit it here.
160
// virtual void TearDown() {
161
// QuickTest::TearDown();
170
// Now, let's write tests using the QueueTest fixture.
172
// Tests the default constructor.
173
TEST_F(QueueTest, DefaultConstructor) {
174
EXPECT_EQ(0, q0_.Size());
178
TEST_F(QueueTest, Dequeue) {
179
int * n = q0_.Dequeue();
180
EXPECT_TRUE(n == NULL);
183
EXPECT_TRUE(n != NULL);
185
EXPECT_EQ(0, q1_.Size());
189
EXPECT_TRUE(n != NULL);
191
EXPECT_EQ(1, q2_.Size());
195
// If necessary, you can derive further test fixtures from a derived
196
// fixture itself. For example, you can derive another fixture from
197
// QueueTest. Google Test imposes no limit on how deep the hierarchy
198
// can be. In practice, however, you probably don't want it to be too
199
// deep as to be confusing.