Merge remote-tracking branch 'origin/master'

Conflicts:
	README.md
	include/internal/catch_version.hpp
	single_include/catch.hpp

.gitattributes

@@ -0,0 +1,11 @@
+# This sets the default behaviour, overriding core.autocrlf
+* text=auto
+
+# All source files should have unix line-endings in the repository,
+# but convert to native line-endings on checkout
+*.cpp text
+*.h text
+*.hpp text
+
+# Windows specific files should retain windows line-endings
+*.sln text eol=crlf

.travis.yml

@@ -0,0 +1,19 @@
+language: cpp
+
+compiler:
+  - clang
+  - gcc
+
+env:
+  - BUILD_TYPE=Debug
+  - BUILD_TYPE=Release
+
+install:
+  - cmake -Hprojects/CMake -BBuild -DCMAKE_BUILD_TYPE=$BUILD_TYPE
+  - cd Build
+  - make
+  - cd ..
+
+script:
+  - cd Build
+  - ctest -V

docs/assertions.md

@@ -1,6 +1,6 @@
 # Assertion Macros
 
-Most test frameworks have a large collection of assertion macros to capture all possible conditional forms (_EQUALS, _NOTEQUALS, _GREATER_THAN etc).
+Most test frameworks have a large collection of assertion macros to capture all possible conditional forms (```_EQUALS```, ```_NOTEQUALS```, ```_GREATER_THAN``` etc).
 
 Catch is different. Because it decomposes natural C-style conditional expressions most of these forms are reduced to one or two that you will use all the time. That said there are a rich set of auxilliary macros as well. We'll describe all of these here.
 
@@ -8,11 +8,12 @@ Most of these macros come in two forms:
 
 ## Natural Expressions
 
-The REQUIRE family of macros tests an expression and aborts the test case if it fails.
+The ```REQUIRE``` family of macros tests an expression and aborts the test case if it fails.
-The CHECK family are equivalent but execution continues in the same test case even if the assertion fails. This is useful if you have a series of essentially orthoginal assertions and it is useful to see all the results rather than stopping at the first failure.
+The ```CHECK``` family are equivalent but execution continues in the same test case even if the assertion fails. This is useful if you have a series of essentially orthoginal assertions and it is useful to see all the results rather than stopping at the first failure.
+
+* **REQUIRE(** _expression_ **)** and  
+* **CHECK(** _expression_ **)**
 
-**REQUIRE(** _expression_ **)** and  
-**CHECK(** _expression_ **)**  
 Evaluates the expression and records the result. If an exception is thrown it is caught, reported, and counted as a failure. These are the macros you will use most of  the time
 
 Examples:
@@ -22,8 +23,9 @@ CHECK( str == "string value" );
 CHECK( thisReturnsTrue() );
 REQUIRE( i == 42 );
 ```
-**REQUIRE_FALSE(** _expression_ **)** and  
+* **REQUIRE_FALSE(** _expression_ **)** and  
-**CHECK_FALSE(** _expression_ **)**  
+* **CHECK_FALSE(** _expression_ **)**
+
 Evaluates the expression and records the _logical NOT_ of the result. If an exception is thrown it is caught, reported, and counted as a failure.
 (these forms exist as a workaround for the fact that ! prefixed expressions cannot be decomposed).
 
@@ -34,24 +36,27 @@ REQUIRE_FALSE( thisReturnsFalse() );
 
 ## Exceptions
 
-**REQUIRE_THROWS(** _expression_ **)** and  
+* **REQUIRE_THROWS(** _expression_ **)** and  
-**CHECK_THROWS(** _expression_ **)**  
+* **CHECK_THROWS(** _expression_ **)**
+
 Expects that an exception (of any type) is be thrown during evaluation of the expression.
 
-**REQUIRE_THROWS_AS(** _expression_ and _exception type_ **)** and  
+* **REQUIRE_THROWS_AS(** _expression_ and _exception type_ **)** and  
-**CHECK_THROWS_AS(** _expression_, _exception type_ **)**  
+* **CHECK_THROWS_AS(** _expression_, _exception type_ **)**
+
 Expects that an exception of the _specified type_ is thrown during evaluation of the expression.
 
-**REQUIRE_NOTHROW(** _expression_ **)** and  
+* **REQUIRE_NOTHROW(** _expression_ **)** and  
-**CHECK_NOTHROW(** _expression_ **)**  
+* **CHECK_NOTHROW(** _expression_ **)**
+
 Expects that no exception is thrown during evaluation of the expression.
 
 ## Matcher expressions
 
 To support Matchers a slightly different form is used. Matchers will be more fully documented elsewhere. *Note that Matchers are still at early stage development and are subject to change.*
 
-**REQUIRE_THAT(** _lhs_, __matcher call__ **)** and  
+* **REQUIRE_THAT(** _lhs_, _matcher call_ **)** and  
-**CHECK_THAT(** _lhs_, __matcher call__ **)**  
+* **CHECK_THAT(** _lhs_, _matcher call_ **)**  
 
 
 ---

docs/command-line.md

@@ -1,4 +1,4 @@
-CATCH works quite nicely without any command line options at all - but for those times when you want greater control the following options are available.
+Catch works quite nicely without any command line options at all - but for those times when you want greater control the following options are available.
 Note that options are described according to the following pattern:
 
 <a href="#test">     `    <test-spec> ...`</a><br />
@@ -12,7 +12,7 @@ Note that options are described according to the following pattern:
 <a href="#nothrow">  `    -e, --nothrow`</a><br />
 <a href="#usage">    `    -h, -?, --help`</a><br />
 
-<a name="test" />
+<a id="test"></a>
 ## Specifying which tests to run
 
 <pre>&lt;test-spec> ...</pre>
@@ -43,13 +43,13 @@ a* ~ab* abc             Matches all tests that start with 'a', except those that
 </pre>
 
 Names within square brackets are interpreted as tags.
-A series of tags form an AND expression wheras a comma seperated sequence forms an OR expression. e.g.:
+A series of tags form an AND expression wheras a comma-separated sequence forms an OR expression. e.g.:
 
 <pre>[one][two],[three]</pre>
 This matches all tests tagged `[one]` and `[two]`, as well as all tests tagged `[three]`
 
 
-<a name="reporter" />
+<a id="reporter"></a>
 ## Choosing a reporter to use
 
 <pre>-r, --reporter &lt;reporter></pre>
@@ -64,21 +64,21 @@ The bundled reporters are:
 
 The JUnit reporter is an xml format that follows the structure of the JUnit XML Report ANT task, as consumed by a number of third-party tools, including Continuous Integration servers such as Hudson. If not otherwise needed, the standard XML reporter is preferred as this is a streaming reporter, whereas the Junit reporter needs to hold all its results until the end so it can write the overall results into attributes of the root node.
 
-<a name="break" />
+<a id="break"></a>
 ## Breaking into the debugger
 <pre>-b, --break</pre>
 
 In some IDEs (currently XCode and Visual Studio) it is possible for Catch to break into the debugger on a test failure. This can be very helpful during debug sessions - especially when there is more than one path through a particular test.
 In addition to the command line option, ensure you have built your code with the DEBUG preprocessor symbol
 
-<a name="success" />
+<a id="success"></a>
 ## Showing results for successful tests
 <pre>-s, --success</pre>
 
 Usually you only want to see reporting for failed tests. Sometimes it's useful to see *all* the output (especially when you don't trust that that test you just added worked first time!).
 To see successul, as well as failing, test results just pass this option. Note that each reporter may treat this option differently. The Junit reporter, for example, logs all results regardless.
 
-<a name="abort" />
+<a id="abort"></a>
 ## Aborting after a certain number of failures
 <pre>-a, --abort
 -x, --abortx [&lt;failure threshold>]
@@ -89,7 +89,7 @@ If a ```CHECK``` assertion fails even the current test case is not aborted.
 
 Sometimes this results in a flood of failure messages and you'd rather just see the first few. Specifying ```-a``` or ```--abort``` on its own will abort the whole test run on the first failed assertion of any kind. Use ```-x``` or ```--abortx``` followed by a number to abort after that number of assertion failures.
 
-<a name="list" />
+<a id="list"></a>
 ## Listing available tests, tags or reporters
 <pre>-l, --list-tests
 -t, --list-tags
@@ -103,20 +103,20 @@ If one or more test-specs have been supplied too then only the matching tests wi
 
 ```--list-reporters``` lists the available reporters.
 
-<a name="output" />
+<a id="output"></a>
 ## Sending output to a file
 <pre>-o, --out &lt;filename>
 </pre>
 
 Use this option to send all output to a file. By default output is sent to stdout (note that uses of stdout and stderr *from within test cases* are redirected and included in the report - so even stderr will effectively end up on stdout).
 
-<a name="name" />
+<a id="name"></a>
 ## Naming a test run
 <pre>-n, --name &lt;name for test run></pre>
 
 If a name is supplied it will be used by the reporter to provide an overall name for the test run. This can be useful if you are sending to a file, for example, and need to distinguish different test runs - either from different Catch executables or runs of the same executable with different options. If not supplied the name is defaulted to the name of the executable.
 
-<a name="nothrow" />
+<a id="nothrow"></a>
 ## Eliding assertions expected to throw
 <pre>-e, --nothrow</pre>
 
@@ -126,7 +126,7 @@ These can be a nuisance in certain debugging environments that may break when ex
 
 When running with this option any throw checking assertions are skipped so as not to contribute additional noise. Be careful if this affects the behaviour of subsequent tests.
 
-<a name="usage" />
+<a id="usage"></a>
 ## Usage
 <pre>-h, -?, --help</pre>
 

docs/contributing.md

@@ -0,0 +1,19 @@
+# Contributing to Catch
+
+So you want to contribute something to Catch? That's great! Whether it's a bug fix, a new feature, support for additional compilers - or just a fix to the documentation - all contributions are very welcome and very much appreciated. Of course so are bug reports and other comments and questions.
+
+If you are contributing to the code base there are a few simple guidelines to keep in mind. This also includes notes to help you find your way around. As this is liable to drift out of date please raise an issue or, better still, a pull request for this file, if you notice that.
+
+## Directory structure
+
+Users of Catch primarily use the single header version. Maintainers should work with the full source (which is still, primarily, in headers). This can be found in the ```include``` folder, but you may prefer to use one of the IDE project files (for MSVC or XCode). These can be found under ```projects/```*IDE Name*```/```*project name*. A number of contributors have proposed make files, and submitted their own versions. At some point these should be made available too.
+
+In addition to the include files and IDE projects there are a number of tests in cpp files. These can all be found in ```projects/SelfTest```. You'll also see a ```SurrogateCpps``` directory in there. This contains a set of cpp files that each ```#include``` a single header. While these files are not essential to compilation they help to keep the implementation headers self-contained. At time of writing this set is not complete but has reasonable coverage. If you add additional headers please try to remember to add a surrogate cpp for it.
+
+The other directories are ```scripts``` which contains a set of python scripts to help in testing Catch as well as generating the single include, and docs, which contains the documentation as a set of markdown files.
+
+ *this document is in-progress...*
+
+---
+
+[Home](../README.md)

docs/reference-index.md

@@ -4,6 +4,7 @@ Before looking at this material be sure to read the [tutorial](tutorial.md)
 
 * [Command Line](command-line.md)
 * [Assertion Macros](assertions.md)
+* [Test cases and sections](test-cases-and-sections.md)
 * [Logging Macros](logging.md)
 * [Supplying your own main()](own-main.md)
 * [Test fixtures](test-fixtures.md)

docs/test-cases-and-sections.md

@@ -0,0 +1,45 @@
+# Test cases and sections
+
+While Catch fully supports the traditional, xUnit, style of class-based fixtures containing test case methods this is not the preferred style.
+
+Instead Catch provides a powerful mechanism for nesting test case sections within a test case. For a more detailed discussion see the [tutorial](tutorial.md#testCasesAndSections).
+
+Test cases and sections are very easy to use in practice:
+
+* **TEST_CASE(** _test name_ \[, _tags_ \] **)**
+* **SECTION(** _section name_ **)**
+
+_test name_ and _section name_ are free form, quoted, strings. The optional _tags_ argument is a quoted string containing one or more tags enclosed in square brackets. Tags are discussed below. Test names must be unique within the Catch executable.
+
+For examples see the [Tutorial](tutorial.md)
+
+## Tags
+
+-{placeholder for documentation of tags}-
+
+## BDD-style test cases
+
+In addition to Catch's take on the classic style of test cases, Catch supports an alternative syntax that allow tests to be written as "executable specifications" (one of the early goals of [Behaviour Driven Development](http://dannorth.net/introducing-bdd/)). This set of macros map on to ```TEST_CASE```s and ```SECTION```s, with a little internal support to make them smoother to work with.
+
+* **SCENARIO(** _scenario name_ \[, _tags_ \] **)**
+
+This macro maps onto ```TEST_CASE``` and works in the same way, except that the test case name will be prefixed by "Scenario: "
+
+* **GIVEN(** _something_ **)**
+* **WHEN(** _something_ **)**
+* **THEN(** _something_ **)**
+
+These macros map onto ```SECTION```s except that the section names are the _something_s prefixed by "given: ", "when: " or "then: " respectively.
+
+* **AND_WHEN(** _something_ **)**
+* **AND_THEN(** _something_ **)**
+
+Similar to ```WHEN``` and ```THEN``` except that the prefixes start with "and ". These are used to chain ```WHEN```s and ```THEN```s together.
+
+When any of these macros are used the console reporter recognises them and formats the test case header such that the Givens, Whens and Thens are aligned to aid readability.
+
+Other than the additional prefixes and the formatting in the console reporter these macros behave exactly as ```TEST_CASE```s and ```SECTION```s. As such there is nothing enforcing the correct sequencing of these macros - that's up to the programmer!
+
+---
+
+[Home](../README.md)

docs/tutorial.md

@@ -87,10 +87,61 @@ Of course there are still more issues to do deal with. For example we'll hit pro
 Although this was a simple test it's been enough to demonstrate a few things about how Catch is used. Let's take moment to consider those before we move on.
 
 1. All we did was ```#define``` one identifier and ```#include``` one header and we got everything - even an implementation of ```main()``` that will [respond to command line arguments](command-line.md). You can only use that ```#define``` in one implementation file, for (hopefully) obvious reasons. Once you have more than one file with unit tests in you'll just ```#include "catch.hpp"``` and go. Usually it's a good idea to have a dedicated implementation file that just has ```#define CATCH_CONFIG_MAIN``` and ```#include "catch.hpp"```. You can also provide your own implementation of main and drive Catch yourself (see [Supplying-your-own-main()](own-main.md).
-2. We introduce test cases with the TEST_CASE macro. This macro takes two arguments - a hierarchical test name (forward slash separated, by convention) and a free-form description. The test name should be unique - and ideally will logically group related tests together like folders in a file system. You can run sets of tests by specifying a wildcarded test name.
+2. We introduce test cases with the TEST_CASE macro. This macro takes one or two arguments - a free form test name and, optionally, one or more tags (for more see <a href="#testCasesAndSections">Test cases and Sections</a>, below. The test name must be unique. You can run sets of tests by specifying a wildcarded test name or a tag expression. See the [command line docs](command-line.md) for more information on running tests.
-3. The name and description arguments are just strings. We haven't had to declare a function or method - or explicitly register the test case anywhere. Behind the scenes a function with a generated name is defined for you, and automatically registered using static registry classes. By abstracting the function name away we can name our tests without the constraints of identifier names.
+3. The name and tags arguments are just strings. We haven't had to declare a function or method - or explicitly register the test case anywhere. Behind the scenes a function with a generated name is defined for you, and automatically registered using static registry classes. By abstracting the function name away we can name our tests without the constraints of identifier names.
 4. We write our individual test assertions using the REQUIRE macro. Rather than a separate macro for each type of condition we express the condition naturally using C/C++ syntax. Behind the scenes a simple set of expression templates captures the left-hand-side and right-hand-side of the expression so we can display the values in our test report. As we'll see later there _are_ other assertion macros - but because of this technique the number of them is drastically reduced.
 
+<a id="testCasesAndSections"></a>
+## Test cases and sections
+
+Most test frameworks have a class-based fixture mechanism. That is, test cases map to methods on a class and common setup and teardown can be performed in ```setup()``` and ```teardown()``` methods (or constructor/ destructor in languages, like C++, that support deterministic destruction).
+
+While Catch fully supports this way of working there are a few problems with the approach. In particular the way your code must be split up, and the blunt granularity (you can only have one setup/ teardown pair across a set of methods - sometimes you want slightly different setup in each method - or you may want several levels of setup. We'll revisit that concept shortly and, hopefully, make it clearer). It was <a href="http://jamesnewkirk.typepad.com/posts/2007/09/why-you-should-.html">problems like these</a> that led James Newkirk, who led the team that built NUnit, to start again from scratch and <a href="http://jamesnewkirk.typepad.com/posts/2007/09/announcing-xuni.html">build xUnit</a>).
+
+Catch takes a different approach (to both NUnut and xUnit) that is a more natural fit for C++ and the C family of languages. This is best explaned through an example:
+
+```c++
+TEST_CASE( "vectors can be sized and resized", "[vector]" ) {
+
+    std::vector<int> v( 5 );
+    
+    REQUIRE( v.size() == 5 );
+    REQUIRE( v.capacity() >= 5 );
+    
+    SECTION( "resizing bigger changes size and capacity" ) {
+        v.resize( 10 );
+        
+        REQUIRE( v.size() == 10 );
+        REQUIRE( v.capacity() >= 10 );
+    }
+    SECTION( "resizing smaller changes size but not capacity" ) {
+        v.resize( 0 );
+        
+        REQUIRE( v.size() == 0 );
+        REQUIRE( v.capacity() >= 5 );
+    }
+    SECTION( "reserving bigger changes capacity but not size" ) {
+        v.reserve( 10 );
+        
+        REQUIRE( v.size() == 5 );
+        REQUIRE( v.capacity() >= 10 );
+    }
+    SECTION( "reserving smaller does not change size or capacity" ) {
+        v.reserve( 0 );
+        
+        REQUIRE( v.size() == 5 );
+        REQUIRE( v.capacity() >= 5 );
+    }
+}
+```
+
+For each ```SECTION``` the ```TEST_CASE``` is executed from the start - so as we enter each section we know that size is 5 and capacity is at least 5. We enforced those requirements with the ```REQUIRE```s at the top level so we can be confident in them.
+This works because the ```SECTION``` macro contains an if statement that calls back into Catch to see if the section should be executed. One leaf section is executed on each run through a ```TEST_CASE```. The other sections are skipped. Next time through the next section is executed, and so on until no new sections are encountered.
+
+So far so good - this is already an improvement on the setup/ teardown approach because now we see our setup code inline and we can use the stack.
+
+-{placeholder for documentation on nested sections}-
+
 ## Next steps
 For more specific information see the [Reference pages](reference-index.md)
 

include/internal/catch_context_impl.hpp

@@ -17,7 +17,7 @@ namespace Catch {
 
     class Context : public IMutableContext {
 
-        Context() : m_config( NULL ) {}
+        Context() : m_config( NULL ), m_runner( NULL ), m_resultCapture( NULL ) {}
         Context( Context const& );
         void operator=( Context const& );
 
@@ -77,9 +77,9 @@ namespace Catch {
         }
 
     private:
+        Ptr<IConfig const> m_config;
         IRunner* m_runner;
         IResultCapture* m_resultCapture;
-        Ptr<IConfig const> m_config;
         std::map<std::string, IGeneratorsForTest*> m_generatorsByTestName;
     };
 

include/internal/catch_list.hpp

@@ -58,7 +58,7 @@ namespace Catch {
                 matchedTests++;
                 Text nameWrapper(   it->getTestCaseInfo().name,
                                     TextAttributes()
-                                        .setWidth( maxNameLen )
+                                        .setWidth( maxNameLen+2 )
                                         .setInitialIndent(2)
                                         .setIndent(4) );
 

include/internal/catch_text.hpp

@@ -23,7 +23,10 @@ namespace Catch {
         std::string remainder = _str;
 
         while( !remainder.empty() ) {
-            assert( lines.size() < 1000 );
+            if( lines.size() >= 1000 ) {
+                lines.push_back( "... message truncated due to excessive size" );
+                return;
+            }
             std::size_t tabPos = std::string::npos;
             std::size_t width = (std::min)( remainder.size(), _attr.width - indent );
             std::size_t pos = remainder.find_first_of( '\n' );

projects/CMake/CMakeLists.txt

@@ -0,0 +1,37 @@
+cmake_minimum_required(VERSION 2.8)
+
+project(Catch C CXX)
+message("configure: Catch/SelfTest")
+
+# define some folders
+set(CATCH_DIR     "${CMAKE_CURRENT_SOURCE_DIR}/../..")
+set(SELF_TEST_DIR ${CATCH_DIR}/projects/SelfTest)
+set(SCRIPTS_DIR   ${CATCH_DIR}/scripts)
+
+# define the sources of the self test
+set(
+    SOURCES
+	${SELF_TEST_DIR}/ApproxTests.cpp
+	${SELF_TEST_DIR}/BDDTests.cpp
+	${SELF_TEST_DIR}/catch_self_test.cpp
+	${SELF_TEST_DIR}/ClassTests.cpp
+	${SELF_TEST_DIR}/CmdLineTests.cpp
+	${SELF_TEST_DIR}/ConditionTests.cpp
+	${SELF_TEST_DIR}/ExceptionTests.cpp
+	${SELF_TEST_DIR}/GeneratorTests.cpp
+	${SELF_TEST_DIR}/MessageTests.cpp
+	${SELF_TEST_DIR}/MiscTests.cpp
+	${SELF_TEST_DIR}/SectionTrackerTests.cpp
+	${SELF_TEST_DIR}/TestMain.cpp
+	${SELF_TEST_DIR}/TrickyTests.cpp
+	${SELF_TEST_DIR}/VariadicMacrosTests.cpp
+)
+
+# configure the executable
+include_directories(${CATCH_DIR}/include)
+add_executable(SelfTest ${SOURCES})
+
+# configure unit tests via ctest
+enable_testing()
+add_test(NAME SelfTest_run COMMAND SelfTest)
+#add_test(NAME SelfTest_run COMMAND python ${SCRIPTS_DIR}/approvalTests.py "${CMAKE_CURRENT_BINARY_DIR}/SelfTest")

projects/SelfTest/Baselines/console.std.approved.txt

@@ -708,5 +708,5 @@ with expansion:
   "first" == "second"
 
 ===============================================================================
-121 test cases - 35 failed (744 assertions - 90 failed)
+122 test cases - 35 failed (753 assertions - 90 failed)
 

projects/SelfTest/Baselines/junit.sw.approved.txt

@@ -1,5 +1,5 @@
 <testsuites>
-  <testsuite name="~_" errors="10" failures="99" tests="763" hostname="tbd" time="{duration}" timestamp="tbd">
+  <testsuite name="~_" errors="10" failures="99" tests="772" hostname="tbd" time="{duration}" timestamp="tbd">
     <testcase classname="global" name="./succeeding/Approx/simple" time="{duration}"/>
     <testcase classname="global" name="./succeeding/Approx/epsilon" time="{duration}"/>
     <testcase classname="global" name="./succeeding/Approx/float" time="{duration}"/>
@@ -466,7 +466,8 @@ An error
     <testcase classname="global" name="selftest/test filters" time="{duration}"/>
     <testcase classname="global" name="selftest/filter/prefix wildcard" time="{duration}"/>
     <testcase classname="global" name="selftest/filter/wildcard at both ends" time="{duration}"/>
-    <testcase classname="selftest/tags" name="one tag" time="{duration}"/>
+    <testcase classname="selftest/tags" name="single [one] tag" time="{duration}"/>
+    <testcase classname="selftest/tags" name="single [two] tag" time="{duration}"/>
     <testcase classname="selftest/tags" name="two tags" time="{duration}"/>
     <testcase classname="selftest/tags" name="complex" time="{duration}"/>
     <testcase classname="selftest/tags" name="one tag with characters either side" time="{duration}"/>
@@ -491,6 +492,7 @@ hello
       </system-out>
     </testcase>
     <testcase classname="global" name="Text can be formatted using the Text class" time="{duration}"/>
+    <testcase classname="global" name="Long text is truncted" time="{duration}"/>
     <testcase classname="global" name="./succeeding/Tricky/std::pair" time="{duration}"/>
     <testcase classname="global" name="./inprogress/failing/Tricky/trailing expression" time="{duration}"/>
     <testcase classname="global" name="./inprogress/failing/Tricky/compound lhs" time="{duration}"/>

projects/SelfTest/TestMain.cpp

@@ -298,7 +298,7 @@ int getArgc( const char * (&)[size] ) {
     return size;
 }
 
-TEST_CASE( "selftest/tags", "" ) {
+TEST_CASE( "selftest/tags", "[tags]" ) {
 
     std::string p1 = "[one]";
     std::string p2 = "[one],[two]";
@@ -306,7 +306,7 @@ TEST_CASE( "selftest/tags", "" ) {
     std::string p4 = "[one][two],[three]";
     std::string p5 = "[one][two]~[.],[three]";
     
-    SECTION( "one tag", "" ) {
+    SECTION( "single [one] tag", "" ) {
         Catch::TestCase oneTag = makeTestCase( NULL, "", "test", "[one]", CATCH_INTERNAL_LINEINFO );
 
         CHECK( oneTag.getTestCaseInfo().description == "" );
@@ -320,6 +320,20 @@ TEST_CASE( "selftest/tags", "" ) {
         CHECK( oneTag.matchesTags( p5 ) == false );
     }
 
+    SECTION( "single [two] tag", "" ) {
+        Catch::TestCase oneTag = makeTestCase( NULL, "", "test", "[two]", CATCH_INTERNAL_LINEINFO );
+
+        CHECK( oneTag.getTestCaseInfo().description == "" );
+        CHECK( oneTag.hasTag( "two" ) );
+        CHECK( oneTag.getTags().size() == 1 );
+
+        CHECK( oneTag.matchesTags( p1 ) == false );
+        CHECK( oneTag.matchesTags( p2 ) == true );
+        CHECK( oneTag.matchesTags( p3 ) == false );
+        CHECK( oneTag.matchesTags( p4 ) == false );
+        CHECK( oneTag.matchesTags( p5 ) == false );
+    }
+
     SECTION( "two tags", "" ) {
         Catch::TestCase twoTags= makeTestCase( NULL, "", "test", "[one][two]", CATCH_INTERNAL_LINEINFO );
 
@@ -567,3 +581,15 @@ TEST_CASE( "Text can be formatted using the Text class", "" ) {
     
     CHECK( Text( "hi there", narrow ).toString() == "hi\nthere" );
 }
+
+TEST_CASE( "Long text is truncted", "[Text][Truncated]" ) {
+
+    std::string longLine( 90, '*' );
+
+    std::ostringstream oss;
+    for(int i = 0; i < 600; ++i )
+        oss << longLine << longLine << "\n";
+    Text t( oss.str() );
+    CHECK_THAT( t.toString(), EndsWith( "... message truncated due to excessive size" ) );
+    
+}

projects/VS2010/TestCatch/TestCatch/TestCatch.vcxproj

@@ -91,6 +91,10 @@
     </Link>
   </ItemDefinitionGroup>
   <ItemGroup>
+    <ClCompile Include="..\..\..\SelfTest\ApproxTests.cpp" />
+    <ClCompile Include="..\..\..\SelfTest\BDDTests.cpp" />
+    <ClCompile Include="..\..\..\SelfTest\CmdLineTests.cpp" />
+    <ClCompile Include="..\..\..\SelfTest\SectionTrackerTests.cpp" />
     <ClCompile Include="..\..\..\SelfTest\TestMain.cpp" />
     <ClCompile Include="..\..\..\SelfTest\catch_self_test.cpp" />
     <ClCompile Include="..\..\..\SelfTest\ClassTests.cpp" />
@@ -100,6 +104,7 @@
     <ClCompile Include="..\..\..\SelfTest\MessageTests.cpp" />
     <ClCompile Include="..\..\..\SelfTest\MiscTests.cpp" />
     <ClCompile Include="..\..\..\SelfTest\TrickyTests.cpp" />
+    <ClCompile Include="..\..\..\SelfTest\VariadicMacrosTests.cpp" />
   </ItemGroup>
   <ItemGroup>
     <ClInclude Include="..\..\..\..\include\catch.hpp" />