rj_schema 0.2.2 → 1.0.0

data/ext/rj_schema/rapidjson/thirdparty/gtest/googletest/docs/{FAQ.md → faq.md}

@@ -1,7 +1,7 @@
 
 
 If you cannot find the answer to your question here, and you have read
-[Primer](Primer.md) and [AdvancedGuide](AdvancedGuide.md), send it to
+[Primer](primer.md) and [AdvancedGuide](advanced.md), send it to
 googletestframework@googlegroups.com.
 
 ## Why should I use Google Test instead of my favorite C++ testing framework? ##
@@ -28,11 +28,11 @@ list can help you decide whether it is for you too.
   * `SCOPED_TRACE` helps you understand the context of an assertion failure when it comes from inside a sub-routine or loop.
   * You can decide which tests to run using name patterns.  This saves time when you want to quickly reproduce a test failure.
   * Google Test can generate XML test result reports that can be parsed by popular continuous build system like Hudson.
-  * Simple things are easy in Google Test, while hard things are possible: in addition to advanced features like [global test environments](AdvancedGuide.md#global-set-up-and-tear-down) and tests parameterized by [values](AdvancedGuide.md#value-parameterized-tests) or [types](docs/AdvancedGuide.md#typed-tests), Google Test supports various ways for the user to extend the framework -- if Google Test doesn't do something out of the box, chances are that a user can implement the feature using Google Test's public API, without changing Google Test itself.  In particular, you can:
-    * expand your testing vocabulary by defining [custom predicates](AdvancedGuide.md#predicate-assertions-for-better-error-messages),
-    * teach Google Test how to [print your types](AdvancedGuide.md#teaching-google-test-how-to-print-your-values),
-    * define your own testing macros or utilities and verify them using Google Test's [Service Provider Interface](AdvancedGuide.md#catching-failures), and
-    * reflect on the test cases or change the test output format by intercepting the [test events](AdvancedGuide.md#extending-google-test-by-handling-test-events).
+  * Simple things are easy in Google Test, while hard things are possible: in addition to advanced features like [global test environments](advanced.md#global-set-up-and-tear-down) and tests parameterized by [values](advanced.md#value-parameterized-tests) or [types](docs/advanced.md#typed-tests), Google Test supports various ways for the user to extend the framework -- if Google Test doesn't do something out of the box, chances are that a user can implement the feature using Google Test's public API, without changing Google Test itself.  In particular, you can:
+    * expand your testing vocabulary by defining [custom predicates](advanced.md#predicate-assertions-for-better-error-messages),
+    * teach Google Test how to [print your types](advanced.md#teaching-google-test-how-to-print-your-values),
+    * define your own testing macros or utilities and verify them using Google Test's [Service Provider Interface](advanced.md#catching-failures), and
+    * reflect on the test cases or change the test output format by intercepting the [test events](advanced.md#extending-google-test-by-handling-test-events).
 
 ## I'm getting warnings when compiling Google Test.  Would you fix them? ##
 
@@ -54,7 +54,7 @@ Underscore (`_`) is special, as C++ reserves the following to be used by
 the compiler and the standard library:
 
   1. any identifier that starts with an `_` followed by an upper-case letter, and
-  1. any identifier that containers two consecutive underscores (i.e. `__`) _anywhere_ in its name.
+  1. any identifier that contains two consecutive underscores (i.e. `__`) _anywhere_ in its name.
 
 User code is _prohibited_ from using such identifiers.
 
@@ -76,7 +76,7 @@ for simplicity we just say that it cannot start with `_`.).
 
 It may seem fine for `TestCaseName` and `TestName` to contain `_` in the
 middle.  However, consider this:
-``` cpp
+```c++
 TEST(Time, Flies_Like_An_Arrow) { ... }
 TEST(Time_Flies, Like_An_Arrow) { ... }
 ```
@@ -102,9 +102,9 @@ Then every user of your machine can write tests without
 recompiling Google Test.
 
 This seemed like a good idea, but it has a
-got-cha: every user needs to compile his tests using the _same_ compiler
+got-cha: every user needs to compile their tests using the _same_ compiler
 flags used to compile the installed Google Test libraries; otherwise
-he may run into undefined behaviors (i.e. the tests can behave
+they may run into undefined behaviors (i.e. the tests can behave
 strangely and may even crash for no obvious reasons).
 
 Why?  Because C++ has this thing called the One-Definition Rule: if
@@ -242,7 +242,7 @@ of this approach:
   1. Throwing in a destructor is undefined behavior in C++.  Not using exceptions means Google Test's assertions are safe to use in destructors.
   1. The `EXPECT_*` family of macros will continue even after a failure, allowing multiple failures in a `TEST` to be reported in a single run. This is a popular feature, as in C++ the edit-compile-test cycle is usually quite long and being able to fixing more than one thing at a time is a blessing.
   1. If assertions are implemented using exceptions, a test may falsely ignore a failure if it's caught by user code:
-``` cpp
+```c++
 try { ... ASSERT_TRUE(...) ... }
 catch (...) { ... }
 ```
@@ -259,13 +259,13 @@ macro for both cases.  One possibility is to provide only one macro
 for tests with fixtures, and require the user to define an empty
 fixture sometimes:
 
-``` cpp
+```c++
 class FooTest : public ::testing::Test {};
 
 TEST_F(FooTest, DoesThis) { ... }
 ```
 or
-``` cpp
+```c++
 typedef ::testing::Test FooTest;
 
 TEST_F(FooTest, DoesThat) { ... }
@@ -293,7 +293,7 @@ possibly allows.  In particular:
   * The runner-style requires to split the information into two pieces: the definition of the death test itself, and the specification for the runner on how to run the death test and what to expect.  The death test would be written in C++, while the runner spec may or may not be.  A user needs to carefully keep the two in sync. `ASSERT_DEATH(statement, expected_message)` specifies all necessary information in one place, in one language, without boilerplate code. It is very declarative.
   * `ASSERT_DEATH` has a similar syntax and error-reporting semantics as other Google Test assertions, and thus is easy to learn.
   * `ASSERT_DEATH` can be mixed with other assertions and other logic at your will.  You are not limited to one death test per test method. For example, you can write something like:
-``` cpp
+```c++
     if (FooCondition()) {
       ASSERT_DEATH(Bar(), "blah");
     } else {
@@ -302,7 +302,7 @@ possibly allows.  In particular:
 ```
 If you prefer one death test per test method, you can write your tests in that style too, but we don't want to impose that on the users.  The fewer artificial limitations the better.
   * `ASSERT_DEATH` can reference local variables in the current function, and you can decide how many death tests you want based on run-time information.  For example,
-``` cpp
+```c++
     const int count = GetCount();  // Only known at run time.
     for (int i = 1; i <= count; i++) {
       ASSERT_DEATH({
@@ -335,7 +335,7 @@ as running in a parallel universe, more or less.
 
 If your class has a static data member:
 
-``` cpp
+```c++
 // foo.h
 class Foo {
   ...
@@ -345,7 +345,7 @@ class Foo {
 
 You also need to define it _outside_ of the class body in `foo.cc`:
 
-``` cpp
+```c++
 const int Foo::kBar;  // No initializer here.
 ```
 
@@ -376,7 +376,7 @@ to write tests using each derived fixture.
 
 Typically, your code looks like this:
 
-``` cpp
+```c++
 // Defines a base test fixture.
 class BaseTest : public ::testing::Test {
   protected:
@@ -460,7 +460,7 @@ following benefits:
 You may still want to use `SetUp()/TearDown()` in the following rare cases:
   * If the tear-down operation could throw an exception, you must use `TearDown()` as opposed to the destructor, as throwing in a destructor leads to undefined behavior and usually will kill your program right away. Note that many standard libraries (like STL) may throw when exceptions are enabled in the compiler. Therefore you should prefer `TearDown()` if you want to write portable tests that work with or without exceptions.
   * The assertion macros throw an exception when flag `--gtest_throw_on_failure` is specified. Therefore, you shouldn't use Google Test assertions in a destructor if you plan to run your tests with this flag.
-  * In a constructor or destructor, you cannot make a virtual function call on this object. (You can call a method declared as virtual, but it will be statically bound.) Therefore, if you need to call a method that will be overriden in a derived class, you have to use `SetUp()/TearDown()`.
+  * In a constructor or destructor, you cannot make a virtual function call on this object. (You can call a method declared as virtual, but it will be statically bound.) Therefore, if you need to call a method that will be overridden in a derived class, you have to use `SetUp()/TearDown()`.
 
 ## The compiler complains "no matching function to call" when I use ASSERT\_PREDn. How do I fix it? ##
 
@@ -476,7 +476,7 @@ explicitly telling the compiler which version to pick.
 
 For example, suppose you have
 
-``` cpp
+```c++
 bool IsPositive(int n) {
   return n > 0;
 }
@@ -487,14 +487,14 @@ bool IsPositive(double x) {
 
 you will get a compiler error if you write
 
-``` cpp
+```c++
 EXPECT_PRED1(IsPositive, 5);
 ```
 
 However, this will work:
 
-``` cpp
-EXPECT_PRED1(*static_cast<bool (*)(int)>*(IsPositive), 5);
+```c++
+EXPECT_PRED1(static_cast<bool (*)(int)>(IsPositive), 5);
 ```
 
 (The stuff inside the angled brackets for the `static_cast` operator is the
@@ -502,7 +502,7 @@ type of the function pointer for the `int`-version of `IsPositive()`.)
 
 As another example, when you have a template function
 
-``` cpp
+```c++
 template <typename T>
 bool IsNegative(T x) {
   return x < 0;
@@ -511,15 +511,15 @@ bool IsNegative(T x) {
 
 you can use it in a predicate assertion like this:
 
-``` cpp
-ASSERT_PRED1(IsNegative*<int>*, -5);
+```c++
+ASSERT_PRED1(IsNegative<int>, -5);
 ```
 
 Things are more interesting if your template has more than one parameters. The
 following won't compile:
 
-``` cpp
-ASSERT_PRED2(*GreaterThan<int, int>*, 5, 0);
+```c++
+ASSERT_PRED2(GreaterThan<int, int>, 5, 0);
 ```
 
 
@@ -527,8 +527,8 @@ as the C++ pre-processor thinks you are giving `ASSERT_PRED2` 4 arguments,
 which is one more than expected. The workaround is to wrap the predicate
 function in parentheses:
 
-``` cpp
-ASSERT_PRED2(*(GreaterThan<int, int>)*, 5, 0);
+```c++
+ASSERT_PRED2((GreaterThan<int, int>), 5, 0);
 ```
 
 
@@ -537,13 +537,13 @@ ASSERT_PRED2(*(GreaterThan<int, int>)*, 5, 0);
 Some people had been ignoring the return value of `RUN_ALL_TESTS()`. That is,
 instead of
 
-``` cpp
+```c++
 return RUN_ALL_TESTS();
 ```
 
 they write
 
-``` cpp
+```c++
 RUN_ALL_TESTS();
 ```
 
@@ -562,7 +562,7 @@ is used as the return value of `main()`.
 Due to a peculiarity of C++, in order to support the syntax for streaming
 messages to an `ASSERT_*`, e.g.
 
-``` cpp
+```c++
 ASSERT_EQ(1, Foo()) << "blah blah" << foo;
 ```
 
@@ -591,7 +591,7 @@ the corresponding source code, or use `C-x `` to jump to the next failure.
 
 You don't have to. Instead of
 
-``` cpp
+```c++
 class FooTest : public BaseTest {};
 
 TEST_F(FooTest, Abc) { ... }
@@ -604,7 +604,7 @@ TEST_F(BarTest, Def) { ... }
 ```
 
 you can simply `typedef` the test fixtures:
-``` cpp
+```c++
 typedef BaseTest FooTest;
 
 TEST_F(FooTest, Abc) { ... }
@@ -646,7 +646,7 @@ members of the helper class public.
 
 You have several other options that don't require using `FRIEND_TEST`:
   * Write the tests as members of the fixture class:
-``` cpp
+```c++
 class Foo {
   friend class FooTest;
   ...
@@ -668,7 +668,7 @@ TEST_F(FooTest, Test2) {
 }
 ```
   * In the fixture class, write accessors for the tested class' private members, then use the accessors in your tests:
-``` cpp
+```c++
 class Foo {
   friend class FooTest;
   ...
@@ -689,7 +689,7 @@ TEST_F(FooTest, Test1) {
 }
 ```
   * If the methods are declared **protected**, you can change their access level in a test-only subclass:
-``` cpp
+```c++
 class YourClass {
   ...
  protected: // protected access for testability.
@@ -717,7 +717,7 @@ implementation details and ideally should be kept out of a .h. So often I make
 them free functions instead.
 
 Instead of:
-``` cpp
+```c++
 // foo.h
 class Foo {
   ...
@@ -733,7 +733,7 @@ EXPECT_TRUE(Foo::Func(12345));
 ```
 
 You probably should better write:
-``` cpp
+```c++
 // foo.h
 class Foo {
   ...
@@ -754,7 +754,7 @@ EXPECT_TRUE(internal::Func(12345));
 
 ## I would like to run a test several times with different parameters. Do I need to write several similar copies of it? ##
 
-No. You can use a feature called [value-parameterized tests](AdvancedGuide.md#Value_Parameterized_Tests) which
+No. You can use a feature called [value-parameterized tests](advanced.md#Value_Parameterized_Tests) which
 lets you repeat your tests with different parameters, without defining it more than once.
 
 ## How do I test a file that defines main()? ##
@@ -774,7 +774,7 @@ Then `foo.cc` can be easily tested.
 If you are adding tests to an existing file and don't want an intrusive change
 like this, there is a hack: just include the entire `foo.cc` file in your unit
 test. For example:
-``` cpp
+```c++
 // File foo_unittest.cc
 
 // The headers section
@@ -805,7 +805,7 @@ reference global and/or local variables, and can be:
 
 Some examples are shown here:
 
-``` cpp
+```c++
 // A death test can be a simple function call.
 TEST(MyDeathTest, FunctionCall) {
   ASSERT_DEATH(Xyz(5), "Xyz failed");
@@ -849,7 +849,7 @@ expression syntax
 (http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions).
 On Windows, it uses a limited variant of regular expression
 syntax. For more details, see the
-[regular expression syntax](AdvancedGuide.md#Regular_Expression_Syntax).
+[regular expression syntax](advanced.md#Regular_Expression_Syntax).
 
 ## I have a fixture class Foo, but TEST\_F(Foo, Bar) gives me error "no matching function for call to Foo::Foo()". Why? ##
 
@@ -884,7 +884,7 @@ inefficient and makes the semantics unclean.
 If we were to determine the order of tests based on test name instead of test
 case name, then we would have a problem with the following situation:
 
-``` cpp
+```c++
 TEST_F(FooTest, AbcDeathTest) { ... }
 TEST_F(FooTest, Uvw) { ... }
 
@@ -903,7 +903,7 @@ You don't have to, but if you like, you may split up the test case into
 `FooTest` and `FooDeathTest`, where the names make it clear that they are
 related:
 
-``` cpp
+```c++
 class FooTest : public ::testing::Test { ... };
 
 TEST_F(FooTest, Abc) { ... }
@@ -956,16 +956,15 @@ using gtest-md.vcproj instead of gtest.vcproj.
 
 ## I put my tests in a library and Google Test doesn't run them. What's happening? ##
 Have you read a
-[warning](Primer.md#important-note-for-visual-c-users) on
+[warning](primer.md#important-note-for-visual-c-users) on
 the Google Test Primer page?
 
 ## I want to use Google Test with Visual Studio but don't know where to start. ##
-Many people are in your position and one of the posted his solution to
-our mailing list.
+Many people are in your position and one of them posted his solution to our mailing list.
 
 ## I am seeing compile errors mentioning std::type\_traits when I try to use Google Test on Solaris. ##
 Google Test uses parts of the standard C++ library that SunStudio does not support.
-Our users reported success using alternative implementations. Try running the build after runing this commad:
+Our users reported success using alternative implementations. Try running the build after running this command:
 
 `export CC=cc CXX=CC CXXFLAGS='-library=stlport4'`
 
@@ -1006,16 +1005,16 @@ Specifically, if both Google Test and some other code define macro
 ```
 to the compiler flags to tell Google Test to change the macro's name
 from `FOO` to `GTEST_FOO`. For example, with `-DGTEST_DONT_DEFINE_TEST=1`, you'll need to write
-``` cpp
+```c++
   GTEST_TEST(SomeTest, DoesThis) { ... }
 ```
 instead of
-``` cpp
+```c++
   TEST(SomeTest, DoesThis) { ... }
 ```
 in order to define a test.
 
-Currently, the following `TEST`, `FAIL`, `SUCCEED`, and the basic comparison assertion macros can have alternative names. You can see the full list of covered macros [here](http://www.google.com/codesearch?q=if+!GTEST_DONT_DEFINE_\w%2B+package:http://googletest\.googlecode\.com+file:/include/gtest/gtest.h). More information can be found in the "Avoiding Macro Name Clashes" section of the README file.
+Currently, the following `TEST`, `FAIL`, `SUCCEED`, and the basic comparison assertion macros can have . You can see the full list of covered macros [here](../include/gtest/gtest.h). More information can be found in the "Avoiding Macro Name Clashes" section of the README file.
 
 
 ## Is it OK if I have two separate `TEST(Foo, Bar)` test methods defined in different namespaces? ##
@@ -1024,7 +1023,7 @@ Yes.
 
 The rule is **all test methods in the same test case must use the same fixture class**. This means that the following is **allowed** because both tests use the same fixture class (`::testing::Test`).
 
-``` cpp
+```c++
 namespace foo {
 TEST(CoolTest, DoSomething) {
   SUCCEED();
@@ -1035,12 +1034,12 @@ namespace bar {
 TEST(CoolTest, DoSomething) {
   SUCCEED();
 }
-}  // namespace foo
+}  // namespace bar
 ```
 
 However, the following code is **not allowed** and will produce a runtime error from Google Test because the test methods are using different test fixture classes with the same test case name.
 
-``` cpp
+```c++
 namespace foo {
 class CoolTest : public ::testing::Test {};  // Fixture foo::CoolTest
 TEST_F(CoolTest, DoSomething) {
@@ -1053,7 +1052,7 @@ class CoolTest : public ::testing::Test {};  // Fixture: bar::CoolTest
 TEST_F(CoolTest, DoSomething) {
   SUCCEED();
 }
-}  // namespace foo
+}  // namespace bar
 ```
 
 ## How do I build Google Testing Framework with Xcode 4? ##
@@ -1061,6 +1060,12 @@ TEST_F(CoolTest, DoSomething) {
 If you try to build Google Test's Xcode project with Xcode 4.0 or later, you may encounter an error message that looks like
 "Missing SDK in target gtest\_framework: /Developer/SDKs/MacOSX10.4u.sdk". That means that Xcode does not support the SDK the project is targeting. See the Xcode section in the [README](../README.md) file on how to resolve this.
 
+## How do I easily discover the flags needed for GoogleTest? ##
+
+GoogleTest (and GoogleMock) now support discovering all necessary flags using pkg-config.
+See the [pkg-config guide](Pkgconfig.md) on how you can easily discover all compiler and
+linker flags using pkg-config.
+
 ## My question is not covered in your FAQ! ##
 
 If you cannot find the answer to your question in this FAQ, there are

data/ext/rj_schema/rapidjson/thirdparty/gtest/googletest/docs/{Primer.md → primer.md}

@@ -23,6 +23,40 @@ So let's go!
 _Note:_ We sometimes refer to Google C++ Testing Framework informally
 as _Google Test_.
 
+# Beware of the nomenclature #
+
+_Note:_ There might be some confusion of idea due to different
+definitions of the terms _Test_, _Test Case_ and _Test Suite_, so beware
+of misunderstanding these.
+
+Historically, the Google C++ Testing Framework started to use the term
+_Test Case_ for grouping related tests, whereas current publications
+including the International Software Testing Qualifications Board
+([ISTQB](http://www.istqb.org/)) and various textbooks on Software
+Quality use the term _[Test
+Suite](http://glossary.istqb.org/search/test%20suite)_ for this.
+
+The related term _Test_, as it is used in the Google C++ Testing
+Framework, is corresponding to the term _[Test
+Case](http://glossary.istqb.org/search/test%20case)_ of ISTQB and
+others.
+
+The term _Test_ is commonly of broad enough sense, including ISTQB's
+definition of _Test Case_, so it's not much of a problem here. But the
+term _Test Case_ as used in Google Test is of contradictory sense and thus confusing.
+
+Unfortunately replacing the term _Test Case_ by _Test Suite_ throughout
+the Google C++ Testing Framework is not easy without breaking dependent
+projects, as `TestCase` is part of the public API at various places.
+
+So for the time being, please be aware of the different definitions of
+the terms:
+
+Meaning | Google Test Term | [ISTQB](http://www.istqb.org/) Term
+------- | ---------------- | -----------------------------------
+Exercise a particular program path with specific input values and verify the results | [TEST()](#simple-tests) | [Test Case](http://glossary.istqb.org/search/test%20case)
+A set of several tests related to one component | [Test Case](#basic-concepts) | [Test Suite](http://glossary.istqb.org/search/test%20suite)
+
 # Setting up a New Test Project #
 
 To write a test program using Google Test, you need to compile Google
@@ -179,7 +213,7 @@ two `string` objects, use `EXPECT_EQ`, `EXPECT_NE`, and etc instead.
 
 | **Fatal assertion** | **Nonfatal assertion** | **Verifies** |
 |:--------------------|:-----------------------|:-------------|
-| `ASSERT_STREQ(`_str1_`, `_str2_`);`    | `EXPECT_STREQ(`_str1_`, `_str_2`);`     | the two C strings have the same content |
+| `ASSERT_STREQ(`_str1_`, `_str2_`);`    | `EXPECT_STREQ(`_str1_`, `_str2_`);`     | the two C strings have the same content |
 | `ASSERT_STRNE(`_str1_`, `_str2_`);`    | `EXPECT_STRNE(`_str1_`, `_str2_`);`     | the two C strings have different content |
 | `ASSERT_STRCASEEQ(`_str1_`, `_str2_`);`| `EXPECT_STRCASEEQ(`_str1_`, `_str2_`);` | the two C strings have the same content, ignoring case |
 | `ASSERT_STRCASENE(`_str1_`, `_str2_`);`| `EXPECT_STRCASENE(`_str1_`, `_str2_`);` | the two C strings have different content, ignoring case |
@@ -195,7 +229,7 @@ A `NULL` pointer and an empty string are considered _different_.
 _Availability_: Linux, Windows, Mac.
 
 See also: For more string comparison tricks (substring, prefix, suffix, and
-regular expression matching, for example), see the [Advanced Google Test Guide](AdvancedGuide.md).
+regular expression matching, for example), see the [Advanced Google Test Guide](advanced.md).
 
 # Simple Tests #
 
@@ -205,7 +239,7 @@ To create a test:
   1. The test's result is determined by the assertions; if any assertion in the test fails (either fatally or non-fatally), or if the test crashes, the entire test fails. Otherwise, it succeeds.
 
 ```
-TEST(test_case_name, test_name) {
+TEST(testCaseName, testName) {
  ... test body ...
 }
 ```
@@ -256,7 +290,7 @@ To create a fixture, just:
   1. Derive a class from `::testing::Test` . Start its body with `protected:` or `public:` as we'll want to access fixture members from sub-classes.
   1. Inside the class, declare any objects you plan to use.
   1. If necessary, write a default constructor or `SetUp()` function to prepare the objects for each test. A common mistake is to spell `SetUp()` as `Setup()` with a small `u` - don't let that happen to you.
-  1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](FAQ.md#should-i-use-the-constructordestructor-of-the-test-fixture-or-the-set-uptear-down-function).
+  1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](faq.md#should-i-use-the-constructordestructor-of-the-test-fixture-or-the-set-uptear-down-function).
   1. If needed, define subroutines for your tests to share.
 
 When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to
@@ -281,7 +315,7 @@ declaration`".
 
 For each test defined with `TEST_F()`, Google Test will:
   1. Create a _fresh_ test fixture at runtime
-  1. Immediately initialize it via `SetUp()` ,
+  1. Immediately initialize it via `SetUp()`
   1. Run the test
   1. Clean up by calling `TearDown()`
   1. Delete the test fixture.  Note that different tests in the same test case have different test fixture objects, and Google Test always deletes a test fixture before it creates the next one. Google Test does not reuse the same test fixture for multiple tests. Any changes one test makes to the fixture do not affect other tests.
@@ -382,7 +416,7 @@ When invoked, the `RUN_ALL_TESTS()` macro:
   1. Restores the state of all Google Test flags.
   1. Repeats the above steps for the next test, until all tests have run.
 
-In addition, if the text fixture's constructor generates a fatal failure in
+In addition, if the test fixture's constructor generates a fatal failure in
 step 2, there is no point for step 3 - 5 and they are thus skipped. Similarly,
 if step 3 generates a fatal failure, step 4 will be skipped.
 
@@ -460,7 +494,7 @@ int main(int argc, char **argv) {
 
 The `::testing::InitGoogleTest()` function parses the command line for Google
 Test flags, and removes all recognized flags. This allows the user to control a
-test program's behavior via various flags, which we'll cover in [AdvancedGuide](AdvancedGuide.md).
+test program's behavior via various flags, which we'll cover in [AdvancedGuide](advanced.md).
 You must call this function before calling `RUN_ALL_TESTS()`, or the flags
 won't be properly initialized.
 
@@ -488,8 +522,8 @@ There is one more pitfall, though. If you use Google Test as a static library (t
 # Where to Go from Here #
 
 Congratulations! You've learned the Google Test basics. You can start writing
-and running Google Test tests, read some [samples](Samples.md), or continue with
-[AdvancedGuide](AdvancedGuide.md), which describes many more useful Google Test features.
+and running Google Test tests, read some [samples](samples.md), or continue with
+[AdvancedGuide](advanced.md), which describes many more useful Google Test features.
 
 # Known Limitations #