]>
Commit | Line | Data |
---|---|---|
31f18b77 FG |
1 | // Copyright 2005, Google Inc. |
2 | // All rights reserved. | |
3 | // | |
4 | // Redistribution and use in source and binary forms, with or without | |
5 | // modification, are permitted provided that the following conditions are | |
6 | // met: | |
7 | // | |
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 | |
13 | // distribution. | |
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. | |
17 | // | |
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. | |
29 | ||
30 | // A sample program demonstrating using Google C++ testing framework. | |
31 | // | |
32 | // Author: wan@google.com (Zhanyong Wan) | |
33 | ||
34 | ||
35 | // This sample shows how to write a simple unit test for a function, | |
36 | // using Google C++ testing framework. | |
37 | // | |
38 | // Writing a unit test using Google C++ testing framework is easy as 1-2-3: | |
39 | ||
40 | ||
41 | // Step 1. Include necessary header files such that the stuff your | |
42 | // test logic needs is declared. | |
43 | // | |
44 | // Don't forget gtest.h, which declares the testing framework. | |
45 | ||
46 | #include <limits.h> | |
47 | #include "sample1.h" | |
48 | #include "gtest/gtest.h" | |
49 | ||
50 | ||
51 | // Step 2. Use the TEST macro to define your tests. | |
52 | // | |
53 | // TEST has two parameters: the test case name and the test name. | |
54 | // After using the macro, you should define your test logic between a | |
55 | // pair of braces. You can use a bunch of macros to indicate the | |
56 | // success or failure of a test. EXPECT_TRUE and EXPECT_EQ are | |
57 | // examples of such macros. For a complete list, see gtest.h. | |
58 | // | |
59 | // <TechnicalDetails> | |
60 | // | |
61 | // In Google Test, tests are grouped into test cases. This is how we | |
62 | // keep test code organized. You should put logically related tests | |
63 | // into the same test case. | |
64 | // | |
65 | // The test case name and the test name should both be valid C++ | |
66 | // identifiers. And you should not use underscore (_) in the names. | |
67 | // | |
68 | // Google Test guarantees that each test you define is run exactly | |
69 | // once, but it makes no guarantee on the order the tests are | |
70 | // executed. Therefore, you should write your tests in such a way | |
71 | // that their results don't depend on their order. | |
72 | // | |
73 | // </TechnicalDetails> | |
74 | ||
75 | ||
76 | // Tests Factorial(). | |
77 | ||
78 | // Tests factorial of negative numbers. | |
79 | TEST(FactorialTest, Negative) { | |
80 | // This test is named "Negative", and belongs to the "FactorialTest" | |
81 | // test case. | |
82 | EXPECT_EQ(1, Factorial(-5)); | |
83 | EXPECT_EQ(1, Factorial(-1)); | |
84 | EXPECT_GT(Factorial(-10), 0); | |
85 | ||
86 | // <TechnicalDetails> | |
87 | // | |
88 | // EXPECT_EQ(expected, actual) is the same as | |
89 | // | |
90 | // EXPECT_TRUE((expected) == (actual)) | |
91 | // | |
92 | // except that it will print both the expected value and the actual | |
93 | // value when the assertion fails. This is very helpful for | |
94 | // debugging. Therefore in this case EXPECT_EQ is preferred. | |
95 | // | |
96 | // On the other hand, EXPECT_TRUE accepts any Boolean expression, | |
97 | // and is thus more general. | |
98 | // | |
99 | // </TechnicalDetails> | |
100 | } | |
101 | ||
102 | // Tests factorial of 0. | |
103 | TEST(FactorialTest, Zero) { | |
104 | EXPECT_EQ(1, Factorial(0)); | |
105 | } | |
106 | ||
107 | // Tests factorial of positive numbers. | |
108 | TEST(FactorialTest, Positive) { | |
109 | EXPECT_EQ(1, Factorial(1)); | |
110 | EXPECT_EQ(2, Factorial(2)); | |
111 | EXPECT_EQ(6, Factorial(3)); | |
112 | EXPECT_EQ(40320, Factorial(8)); | |
113 | } | |
114 | ||
115 | ||
116 | // Tests IsPrime() | |
117 | ||
118 | // Tests negative input. | |
119 | TEST(IsPrimeTest, Negative) { | |
120 | // This test belongs to the IsPrimeTest test case. | |
121 | ||
122 | EXPECT_FALSE(IsPrime(-1)); | |
123 | EXPECT_FALSE(IsPrime(-2)); | |
124 | EXPECT_FALSE(IsPrime(INT_MIN)); | |
125 | } | |
126 | ||
127 | // Tests some trivial cases. | |
128 | TEST(IsPrimeTest, Trivial) { | |
129 | EXPECT_FALSE(IsPrime(0)); | |
130 | EXPECT_FALSE(IsPrime(1)); | |
131 | EXPECT_TRUE(IsPrime(2)); | |
132 | EXPECT_TRUE(IsPrime(3)); | |
133 | } | |
134 | ||
135 | // Tests positive input. | |
136 | TEST(IsPrimeTest, Positive) { | |
137 | EXPECT_FALSE(IsPrime(4)); | |
138 | EXPECT_TRUE(IsPrime(5)); | |
139 | EXPECT_FALSE(IsPrime(6)); | |
140 | EXPECT_TRUE(IsPrime(23)); | |
141 | } | |
142 | ||
143 | // Step 3. Call RUN_ALL_TESTS() in main(). | |
144 | // | |
145 | // We do this by linking in src/gtest_main.cc file, which consists of | |
146 | // a main() function which calls RUN_ALL_TESTS() for us. | |
147 | // | |
148 | // This runs all the tests you've defined, prints the result, and | |
149 | // returns 0 if successful, or 1 otherwise. | |
150 | // | |
151 | // Did you notice that we didn't register the tests? The | |
152 | // RUN_ALL_TESTS() macro magically knows about all the tests we | |
153 | // defined. Isn't this convenient? |