lmi-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi-commits] [lmi] master 969656f 1/2: Test whats_what() [400]


From: Greg Chicares
Subject: [lmi-commits] [lmi] master 969656f 1/2: Test whats_what() [400]
Date: Tue, 7 Feb 2017 20:43:17 -0500 (EST)

branch: master
commit 969656fe04482269610057ec1278c4723f92ea47
Author: Gregory W. Chicares <address@hidden>
Commit: Gregory W. Chicares <address@hidden>

    Test whats_what() [400]
    
    Reexamining the 2017-02-02T02:00:40Z and 2017-01-27T20:30:54Z commit
    messages, one may speculate that the errors fixed in those commits
    might ultimately have been introduced by mistakenly imitating the
    "triple condition" in whats_what() (even if the proximate cause was
    imagining that 'std::equal(v.begin(), v.end(), u.begin())' would mean
    the same thing as 'v == u' for two vectors regardless of length).
    
    In that painful light, it seemed only prudent to reevaluate the
    conjectured fountainhead of these troubles: whats_what(). New tests
    demonstrate that it does indeed work correctly. The reason why it
    compares a caught exception's what() to an empty string is plainly
    documented now, and an old defect marker calling it into question has
    been removed. It is often not useful to test the exact what-string,
    and since that marker was written a whats_what() overload taking a
    regex argument has been added to provide even more flexibility.
---
 test_tools.hpp      |  8 +++-----
 test_tools_test.cpp | 25 +++++++++++++++++++++++++
 2 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/test_tools.hpp b/test_tools.hpp
index 66c0b0d..7735258 100644
--- a/test_tools.hpp
+++ b/test_tools.hpp
@@ -117,15 +117,13 @@ namespace lmi_test
 ///   - expected: macro argument 'WHAT', the string anticipated.
 ///
 /// Deem the arguments equivalent iff either:
-///   - 'WHAT' is empty; or
+///   - 'WHAT' is empty, indicating that the actual exception's what()
+///      is to be disregarded (not that it is expected to be empty);
 ///   - 'WHAT' exactly matches the actual exception's what(); or
 ///   - 'WHAT' matches the actual exception's what() up to but not
 ///      including any lmi exception-location string. (Some lmi
 ///      exceptions add a newline and the file name and line number,
-///      always beginning "\n[file ").
-///
-/// TODO ?? Probably the first element of the triple condition should
-/// be removed, and tests that rely on it strengthened.
+///      always beginning "\n[file "--cf. LMI_FLUSH).
 
 inline bool whats_what(std::string const& observed, std::string const& 
expected)
 {
diff --git a/test_tools_test.cpp b/test_tools_test.cpp
index b63e838..29c5eba 100644
--- a/test_tools_test.cpp
+++ b/test_tools_test.cpp
@@ -125,6 +125,31 @@ int test_main(int, char*[])
         ,lmi_test::what_regex("^Iteration [0-9]*: failure\\.$")
         );
 
+    // Test whats_what().
+
+    // [Here, '.*$' means what it would mean if this were a regex.]
+    std::string const observed = "xyzzy\n[file .*$";
+    // An expectation given as "" means that the what-string is not to
+    // be tested at all, because it was impossible, difficult, or just
+    // unimportant to specify an actual expectation when the test was
+    // written. It doesn't mean that an empty what-string is expected;
+    // it only means that any what-string is accepted.
+    BOOST_TEST( lmi_test::whats_what(observed, ""));
+    // A full exact match is accepted [and here '.*$' is no regex]:
+    BOOST_TEST( lmi_test::whats_what(observed, "xyzzy\n[file .*$"));
+    // Alternatively, discard any portion of the what-string that
+    // begins with "\n[file " (presumably appended by LMI_FLUSH) and
+    // test that truncated what-string. An exact match is accepted:
+    BOOST_TEST( lmi_test::whats_what(observed, "xyzzy"));
+    // However, partial matches are rejected:
+    BOOST_TEST(!lmi_test::whats_what(observed, "xyzz"));
+    BOOST_TEST(!lmi_test::whats_what(observed, "xyzzy!"));
+    // The expectation must exactly equal either the untruncated or
+    // the truncated what-string; an exact match to a "partially
+    // truncated" what-string is rejected:
+    BOOST_TEST(!lmi_test::whats_what(observed, "xyzzy\n"));
+    BOOST_TEST(!lmi_test::whats_what(observed, "xyzzy\n[file .*"));
+
     return 0;
 }
 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]