aboutsummaryrefslogtreecommitdiffstats
path: root/googletest/docs/Primer.md
diff options
context:
space:
mode:
Diffstat (limited to 'googletest/docs/Primer.md')
-rw-r--r--googletest/docs/Primer.md40
1 files changed, 37 insertions, 3 deletions
diff --git a/googletest/docs/Primer.md b/googletest/docs/Primer.md
index 474c1d2a..384d4d6e 100644
--- a/googletest/docs/Primer.md
+++ b/googletest/docs/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 |
@@ -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.