summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorTobias Markmann <tm@ayena.de>2017-01-10 20:22:26 (GMT)
committerTobias Markmann <tm@ayena.de>2017-01-11 18:23:48 (GMT)
commit3b0cde2e6dbf26a01a59b0004e4041199731cbc8 (patch)
tree0b2ba6addb161f1d3e437a64685ea797341a149b /3rdParty/GoogleTest/src/googletest/samples/sample5_unittest.cc
parenta0c339f80e4585341179edef1898defd21a0d36a (diff)
downloadswift-3b0cde2e6dbf26a01a59b0004e4041199731cbc8.zip
swift-3b0cde2e6dbf26a01a59b0004e4041199731cbc8.tar.bz2
Integrate googletest and googlemock libraries to 3rdParty
googletest and googlemock from release 1.8.0 have been copied to the 3rdParty folder. With this commit tests for Swift project can also written using googletest and googlemock APIs. The test runners will execute test suites written to either test library. Passing —-xml to a test runner will now create two test report XML files, namely $programName-report.cppunit.xml and $programName-report.gtest.xml. The ByteArrayTest has been converted to use googletest instead of googlemock to serve as an example and test the integration. Test-Information: Build all tests via ‘./scons test=all’ and verified all tests are run. Build all tests via ‘./scons test=all checker_report=1’ and verified that two report XML files are generated per test runner executed. Change-Id: I81a9fb2c7ea5612fc1b34eef70ed7e711bfeea81
Diffstat (limited to '3rdParty/GoogleTest/src/googletest/samples/sample5_unittest.cc')
-rw-r--r--3rdParty/GoogleTest/src/googletest/samples/sample5_unittest.cc199
1 files changed, 199 insertions, 0 deletions
diff --git a/3rdParty/GoogleTest/src/googletest/samples/sample5_unittest.cc b/3rdParty/GoogleTest/src/googletest/samples/sample5_unittest.cc
new file mode 100644
index 0000000..43d8e57
--- /dev/null
+++ b/3rdParty/GoogleTest/src/googletest/samples/sample5_unittest.cc
@@ -0,0 +1,199 @@
+// Copyright 2005, Google Inc.
+// All rights reserved.
+//
+// Redistribution and use in source and binary forms, with or without
+// modification, are permitted provided that the following conditions are
+// met:
+//
+// * Redistributions of source code must retain the above copyright
+// notice, this list of conditions and the following disclaimer.
+// * Redistributions in binary form must reproduce the above
+// copyright notice, this list of conditions and the following disclaimer
+// in the documentation and/or other materials provided with the
+// distribution.
+// * Neither the name of Google Inc. nor the names of its
+// contributors may be used to endorse or promote products derived from
+// this software without specific prior written permission.
+//
+// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+//
+// Author: wan@google.com (Zhanyong Wan)
+
+// This sample teaches how to reuse a test fixture in multiple test
+// cases by deriving sub-fixtures from it.
+//
+// When you define a test fixture, you specify the name of the test
+// case that will use this fixture. Therefore, a test fixture can
+// be used by only one test case.
+//
+// Sometimes, more than one test cases may want to use the same or
+// slightly different test fixtures. For example, you may want to
+// make sure that all tests for a GUI library don't leak important
+// system resources like fonts and brushes. In Google Test, you do
+// this by putting the shared logic in a super (as in "super class")
+// test fixture, and then have each test case use a fixture derived
+// from this super fixture.
+
+#include <limits.h>
+#include <time.h>
+#include "sample3-inl.h"
+#include "gtest/gtest.h"
+#include "sample1.h"
+
+// In this sample, we want to ensure that every test finishes within
+// ~5 seconds. If a test takes longer to run, we consider it a
+// failure.
+//
+// We put the code for timing a test in a test fixture called
+// "QuickTest". QuickTest is intended to be the super fixture that
+// other fixtures derive from, therefore there is no test case with
+// the name "QuickTest". This is OK.
+//
+// Later, we will derive multiple test fixtures from QuickTest.
+class QuickTest : public testing::Test {
+ protected:
+ // Remember that SetUp() is run immediately before a test starts.
+ // This is a good place to record the start time.
+ virtual void SetUp() {
+ start_time_ = time(NULL);
+ }
+
+ // TearDown() is invoked immediately after a test finishes. Here we
+ // check if the test was too slow.
+ virtual void TearDown() {
+ // Gets the time when the test finishes
+ const time_t end_time = time(NULL);
+
+ // Asserts that the test took no more than ~5 seconds. Did you
+ // know that you can use assertions in SetUp() and TearDown() as
+ // well?
+ EXPECT_TRUE(end_time - start_time_ <= 5) << "The test took too long.";
+ }
+
+ // The UTC time (in seconds) when the test starts
+ time_t start_time_;
+};
+
+
+// We derive a fixture named IntegerFunctionTest from the QuickTest
+// fixture. All tests using this fixture will be automatically
+// required to be quick.
+class IntegerFunctionTest : public QuickTest {
+ // We don't need any more logic than already in the QuickTest fixture.
+ // Therefore the body is empty.
+};
+
+
+// Now we can write tests in the IntegerFunctionTest test case.
+
+// Tests Factorial()
+TEST_F(IntegerFunctionTest, Factorial) {
+ // Tests factorial of negative numbers.
+ EXPECT_EQ(1, Factorial(-5));
+ EXPECT_EQ(1, Factorial(-1));
+ EXPECT_GT(Factorial(-10), 0);
+
+ // Tests factorial of 0.
+ EXPECT_EQ(1, Factorial(0));
+
+ // Tests factorial of positive numbers.
+ EXPECT_EQ(1, Factorial(1));
+ EXPECT_EQ(2, Factorial(2));
+ EXPECT_EQ(6, Factorial(3));
+ EXPECT_EQ(40320, Factorial(8));
+}
+
+
+// Tests IsPrime()
+TEST_F(IntegerFunctionTest, IsPrime) {
+ // Tests negative input.
+ EXPECT_FALSE(IsPrime(-1));
+ EXPECT_FALSE(IsPrime(-2));
+ EXPECT_FALSE(IsPrime(INT_MIN));
+
+ // Tests some trivial cases.
+ EXPECT_FALSE(IsPrime(0));
+ EXPECT_FALSE(IsPrime(1));
+ EXPECT_TRUE(IsPrime(2));
+ EXPECT_TRUE(IsPrime(3));
+
+ // Tests positive input.
+ EXPECT_FALSE(IsPrime(4));
+ EXPECT_TRUE(IsPrime(5));
+ EXPECT_FALSE(IsPrime(6));
+ EXPECT_TRUE(IsPrime(23));
+}
+
+
+// The next test case (named "QueueTest") also needs to be quick, so
+// we derive another fixture from QuickTest.
+//
+// The QueueTest test fixture has some logic and shared objects in
+// addition to what's in QuickTest already. We define the additional
+// stuff inside the body of the test fixture, as usual.
+class QueueTest : public QuickTest {
+ protected:
+ virtual void SetUp() {
+ // First, we need to set up the super fixture (QuickTest).
+ QuickTest::SetUp();
+
+ // Second, some additional setup for this fixture.
+ q1_.Enqueue(1);
+ q2_.Enqueue(2);
+ q2_.Enqueue(3);
+ }
+
+ // By default, TearDown() inherits the behavior of
+ // QuickTest::TearDown(). As we have no additional cleaning work
+ // for QueueTest, we omit it here.
+ //
+ // virtual void TearDown() {
+ // QuickTest::TearDown();
+ // }
+
+ Queue<int> q0_;
+ Queue<int> q1_;
+ Queue<int> q2_;
+};
+
+
+// Now, let's write tests using the QueueTest fixture.
+
+// Tests the default constructor.
+TEST_F(QueueTest, DefaultConstructor) {
+ EXPECT_EQ(0u, q0_.Size());
+}
+
+// Tests Dequeue().
+TEST_F(QueueTest, Dequeue) {
+ int* n = q0_.Dequeue();
+ EXPECT_TRUE(n == NULL);
+
+ n = q1_.Dequeue();
+ EXPECT_TRUE(n != NULL);
+ EXPECT_EQ(1, *n);
+ EXPECT_EQ(0u, q1_.Size());
+ delete n;
+
+ n = q2_.Dequeue();
+ EXPECT_TRUE(n != NULL);
+ EXPECT_EQ(2, *n);
+ EXPECT_EQ(1u, q2_.Size());
+ delete n;
+}
+
+// If necessary, you can derive further test fixtures from a derived
+// fixture itself. For example, you can derive another fixture from
+// QueueTest. Google Test imposes no limit on how deep the hierarchy
+// can be. In practice, however, you probably don't want it to be too
+// deep as to be confusing.