summaryrefslogtreecommitdiff
path: root/src/mesh/assimp-master/contrib/gtest/samples/sample1_unittest.cc
diff options
context:
space:
mode:
authorsanine <sanine.not@pm.me>2022-03-04 10:47:15 -0600
committersanine <sanine.not@pm.me>2022-03-04 10:47:15 -0600
commit058f98a63658dc1a2579826ba167fd61bed1e21f (patch)
treebcba07a1615a14d943f3af3f815a42f3be86b2f3 /src/mesh/assimp-master/contrib/gtest/samples/sample1_unittest.cc
parent2f8028ac9e0812cb6f3cbb08f0f419e4e717bd22 (diff)
add assimp submodule
Diffstat (limited to 'src/mesh/assimp-master/contrib/gtest/samples/sample1_unittest.cc')
-rw-r--r--src/mesh/assimp-master/contrib/gtest/samples/sample1_unittest.cc153
1 files changed, 153 insertions, 0 deletions
diff --git a/src/mesh/assimp-master/contrib/gtest/samples/sample1_unittest.cc b/src/mesh/assimp-master/contrib/gtest/samples/sample1_unittest.cc
new file mode 100644
index 0000000..aefc4f1
--- /dev/null
+++ b/src/mesh/assimp-master/contrib/gtest/samples/sample1_unittest.cc
@@ -0,0 +1,153 @@
+// 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.
+
+// A sample program demonstrating using Google C++ testing framework.
+//
+// Author: wan@google.com (Zhanyong Wan)
+
+
+// This sample shows how to write a simple unit test for a function,
+// using Google C++ testing framework.
+//
+// Writing a unit test using Google C++ testing framework is easy as 1-2-3:
+
+
+// Step 1. Include necessary header files such that the stuff your
+// test logic needs is declared.
+//
+// Don't forget gtest.h, which declares the testing framework.
+
+#include <limits.h>
+#include "sample1.h"
+#include "gtest/gtest.h"
+
+
+// Step 2. Use the TEST macro to define your tests.
+//
+// TEST has two parameters: the test case name and the test name.
+// After using the macro, you should define your test logic between a
+// pair of braces. You can use a bunch of macros to indicate the
+// success or failure of a test. EXPECT_TRUE and EXPECT_EQ are
+// examples of such macros. For a complete list, see gtest.h.
+//
+// <TechnicalDetails>
+//
+// In Google Test, tests are grouped into test cases. This is how we
+// keep test code organized. You should put logically related tests
+// into the same test case.
+//
+// The test case name and the test name should both be valid C++
+// identifiers. And you should not use underscore (_) in the names.
+//
+// Google Test guarantees that each test you define is run exactly
+// once, but it makes no guarantee on the order the tests are
+// executed. Therefore, you should write your tests in such a way
+// that their results don't depend on their order.
+//
+// </TechnicalDetails>
+
+
+// Tests Factorial().
+
+// Tests factorial of negative numbers.
+TEST(FactorialTest, Negative) {
+ // This test is named "Negative", and belongs to the "FactorialTest"
+ // test case.
+ EXPECT_EQ(1, Factorial(-5));
+ EXPECT_EQ(1, Factorial(-1));
+ EXPECT_GT(Factorial(-10), 0);
+
+ // <TechnicalDetails>
+ //
+ // EXPECT_EQ(expected, actual) is the same as
+ //
+ // EXPECT_TRUE((expected) == (actual))
+ //
+ // except that it will print both the expected value and the actual
+ // value when the assertion fails. This is very helpful for
+ // debugging. Therefore in this case EXPECT_EQ is preferred.
+ //
+ // On the other hand, EXPECT_TRUE accepts any Boolean expression,
+ // and is thus more general.
+ //
+ // </TechnicalDetails>
+}
+
+// Tests factorial of 0.
+TEST(FactorialTest, Zero) {
+ EXPECT_EQ(1, Factorial(0));
+}
+
+// Tests factorial of positive numbers.
+TEST(FactorialTest, Positive) {
+ EXPECT_EQ(1, Factorial(1));
+ EXPECT_EQ(2, Factorial(2));
+ EXPECT_EQ(6, Factorial(3));
+ EXPECT_EQ(40320, Factorial(8));
+}
+
+
+// Tests IsPrime()
+
+// Tests negative input.
+TEST(IsPrimeTest, Negative) {
+ // This test belongs to the IsPrimeTest test case.
+
+ EXPECT_FALSE(IsPrime(-1));
+ EXPECT_FALSE(IsPrime(-2));
+ EXPECT_FALSE(IsPrime(INT_MIN));
+}
+
+// Tests some trivial cases.
+TEST(IsPrimeTest, Trivial) {
+ EXPECT_FALSE(IsPrime(0));
+ EXPECT_FALSE(IsPrime(1));
+ EXPECT_TRUE(IsPrime(2));
+ EXPECT_TRUE(IsPrime(3));
+}
+
+// Tests positive input.
+TEST(IsPrimeTest, Positive) {
+ EXPECT_FALSE(IsPrime(4));
+ EXPECT_TRUE(IsPrime(5));
+ EXPECT_FALSE(IsPrime(6));
+ EXPECT_TRUE(IsPrime(23));
+}
+
+// Step 3. Call RUN_ALL_TESTS() in main().
+//
+// We do this by linking in src/gtest_main.cc file, which consists of
+// a main() function which calls RUN_ALL_TESTS() for us.
+//
+// This runs all the tests you've defined, prints the result, and
+// returns 0 if successful, or 1 otherwise.
+//
+// Did you notice that we didn't register the tests? The
+// RUN_ALL_TESTS() macro magically knows about all the tests we
+// defined. Isn't this convenient?