redsnow 0.3.1 → 0.3.2

data/ext/snowcrash/test/vendor/Catch/LICENSE_1_0.txt

@@ -0,0 +1,23 @@
+Boost Software License - Version 1.0 - August 17th, 2003
+
+Permission is hereby granted, free of charge, to any person or organization
+obtaining a copy of the software and accompanying documentation covered by
+this license (the "Software") to use, reproduce, display, distribute,
+execute, and transmit the Software, and to prepare derivative works of the
+Software, and to permit third-parties to whom the Software is furnished to
+do so, all subject to the following:
+
+The copyright notices in the Software and this entire statement, including
+the above license grant, this restriction and the following disclaimer,
+must be included in all copies of the Software, in whole or in part, and
+all derivative works of the Software, unless such copies or derivative
+works are solely in the form of machine-executable object code generated by
+a source language processor.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
+SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
+FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
+ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.

data/ext/snowcrash/test/vendor/Catch/README.md

@@ -0,0 +1,24 @@
+![catch logo](catch-logo-small.png)
+
+*v1.0 build 5 (master branch)*
+
+# New release with significant changes
+
+[Please see this page for details - including some breaking changes](docs/whats-changed.md)
+
+## What's the Catch?
+
+Catch stands for C++ Automated Test Cases in Headers and is a multi-paradigm automated test framework for C++ and Objective-C (and, maybe, C). It is implemented entirely in a set of header files, but is packaged up as a single header for extra convenience.
+
+## How to use it
+This documentation comprises these three parts:
+
+* [Why do we need yet another C++ Test Framework?](docs/why-catch.md)
+* [Tutorial](docs/tutorial.md) - getting started
+* [Reference section](docs/reference-index.md) - all the details
+
+The documentation will continue until morale improves
+
+## More
+* Issues and bugs can be raised on the [Issue tracker on GitHub](https://github.com/philsquared/Catch/issues)
+* For discussion or questions please use [the dedicated Google Groups forum](https://groups.google.com/forum/?fromgroups#!forum/catch-forum)

data/ext/snowcrash/test/vendor/Catch/docs/assertions.md

@@ -0,0 +1,59 @@
+# Assertion Macros
+
+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.
+
+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 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_ **)**  
+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:
+
+```c++
+CHECK( str == "string value" );
+CHECK( thisReturnsTrue() );
+REQUIRE( i == 42 );
+```
+**REQUIRE_FALSE(** _expression_ **)** and  
+**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).
+
+Example:
+```c++
+REQUIRE_FALSE( thisReturnsFalse() );
+```
+
+## Exceptions
+
+**REQUIRE_THROWS(** _expression_ **)** and  
+**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  
+**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  
+**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  
+**CHECK_THAT(** _lhs_, __matcher call__ **)**  
+
+
+---
+
+[Home](../README.md)

data/ext/snowcrash/test/vendor/Catch/docs/command-line.md

@@ -0,0 +1,137 @@
+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 />
+<a href="#reporter"> `    -r, --reporter`</a><br />
+<a href="#break">    `    -b, --break`</a><br />
+<a href="#success">  `    -s, --success`</a><br />
+<a href="#abort">    `    -a, --abort`</a><br />
+<a href="#list">     `    -l, --list`</a><br />
+<a href="#output">   `    -o, --out`</a><br />
+<a href="#name">     `    -n, --name`</a><br />
+<a href="#nothrow">  `    -e, --nothrow`</a><br />
+<a href="#usage">    `    -h, -?, --help`</a><br />
+
+<a name="test" />
+## Specifying which tests to run
+
+<pre>&lt;test-spec> ...</pre>
+
+Test cases, wildcarded test cases, tags and tag expressions are all passed directly as arguments. Tags are distinguished by being enclosed in square brackets.
+
+If no test specs are supplied then all test cases, except "hidden" tests (tagged ```[hide]``` or, in the legacy case, prefixed by `'./'`) are run
+
+Specs must be enclosed in quotes if they contain spaces. If they do not contain spaces the quotes are optional.
+
+Wildcards consist of the `*` character at the beginning and/or end of test case names and can substitute for any number of any characters (including none).
+
+Test specs are case insensitive.
+
+If a spec is prefixed with `exclude:` or the `~` character then the pattern matches an exclusion. This means that tests matching the pattern are excluded from the set - even if a prior inclusion spec included them. Subsequent inclusion specs will take precendence, however.
+Inclusions and exclusions are evaluated in left-to-right order.
+
+Test case examples:
+
+<pre>thisTestOnly            Matches the test case called, 'thisTestOnly'
+"this test only"        Matches the test case called, 'this test only'
+these*                  Matches all cases starting with 'these'
+exclude:notThis         Matches all tests except, 'notThis'
+~notThis                Matches all tests except, 'notThis'
+~*private*              Matches all tests except those that contain 'private'
+a* ~ab* abc             Matches all tests that start with 'a', except those that
+                        start with 'ab', except 'abc', which is included
+</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.:
+
+<pre>[one][two],[three]</pre>
+This matches all tests tagged `[one]` and `[two]`, as well as all tests tagged `[three]`
+
+
+<a name="reporter" />
+## Choosing a reporter to use
+
+<pre>-r, --reporter &lt;reporter></pre>
+
+A reporter is an object that formats and structures the output of running tests, and potentially summarises the results. By default a console reporter is used that writes, IDE friendly, textual output. Catch comes bundled with some alternative reporters, but more can be added in client code.<br />
+The bundled reporters are:
+
+<pre>-r console
+-r xml
+-r junit
+</pre>
+
+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" />
+## 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" />
+## 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" />
+## Aborting after a certain number of failures
+<pre>-a, --abort
+-x, --abortx [&lt;failure threshold>]
+</pre>
+
+If a ```REQUIRE``` assertion fails the test case aborts, but subsequent test cases are still run.
+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" />
+## Listing available tests, tags or reporters
+<pre>-l, --list-tests
+-t, --list-tags
+--list-reporters
+</pre>
+
+```-l``` or ```--list-tests`` will list all registered tests, along with any tags.
+If one or more test-specs have been supplied too then only the matching tests will be listed.
+
+```-t``` or ```--list-tags``` lists all available tags, along with the number of test cases they match. Again, supplying test specs limits the tags that match.
+
+```--list-reporters``` lists the available reporters.
+
+<a name="output" />
+## 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" />
+## 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" />
+## Eliding assertions expected to throw
+<pre>-e, --nothrow</pre>
+
+Skips all assertions that test that an exception is thrown, e.g. ```REQUIRE_THROWS```.
+
+These can be a nuisance in certain debugging environments that may break when exceptions are thrown (while this is usually optional for handled exceptions, it can be useful to have enabled if you are trying to track down something unexpected).
+
+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" />
+## Usage
+<pre>-h, -?, --help</pre>
+
+Prints the command line arguments to stdout
+
+---
+
+[Home](../README.md)

data/ext/snowcrash/test/vendor/Catch/docs/logging.md

@@ -0,0 +1,52 @@
+# Logging macros
+
+Additional messages can be logged during a test case.
+
+## Streaming macros
+
+All these macros allow heterogenous sequences of values to be streaming using the insertion operator (```<<```) in the same way that std::ostream, std::cout, etc support it.
+
+E.g.:
+```c++
+INFO( "The number is " << i );
+```
+
+(Note that there is no initial ```<<``` - instead the insertion sequence is placed in parentheses.)
+These macros come in three forms:
+
+**INFO(** _message expression_ **)**
+
+The message is logged to a buffer, but only reported with the next assertion that is logged. This allows you to log contextual information in case of failures which is not shown during a successful test run (for the console reporter, without -s). Messages are removed from the buffer at the end of their scope, so may be used, for example, in loops.
+
+**WARN(** _message expression_ **)**
+
+The message is always reported but does not fail the test.
+
+**FAIL(** _message expression_ **)**
+
+The message is reported and the test case fails.
+
+## Quickly capture a variable value
+
+**CAPTURE(** _expression_ **)**
+
+Sometimes you just want to log the name and value of a variable. While you can easily do this with the INFO macro, above, as a convenience the CAPTURE macro handles the stringising of the variable name for you (actually it works with any expression, not just variables).
+
+E.g.
+```c++
+CAPTURE( theAnswer );
+```
+
+This would log something like:
+
+<pre>"theAnswer := 42"</pre>
+
+## Deprecated macros
+
+**SCOPED_INFO and SCOPED_CAPTURE**
+
+These macros are now deprecated and are just aliases for INFO and CAPTURE (which were not previously scoped).
+
+---
+
+[Home](../README.md)

data/ext/snowcrash/test/vendor/Catch/docs/own-main.md

@@ -0,0 +1,68 @@
+# Supplying main() yourself
+
+The easiest way to use Catch is to let it supply ```main()``` for you and handle configuring itself from the command line.
+
+This is achieved by writing ```#define CATCH_CONFIG_MAIN``` before the ```#include "catch.hpp"``` in *exactly one* source file.
+
+Sometimes, though, you need to write your own version of main(). You can do this by writing ```#define CATCH_CONFIG_RUNNER``` instead. Now you are free to write ```main()``` as normal and call into Catch yourself manually.
+
+You now have a lot of flexibility - but here are three recipes to get your started:
+
+## Let Catch take full control of args and config
+
+If you just need to have code that executes before and/ or after Catch this is the simplest option.
+
+```c++
+#define CATCH_CONFIG_RUNNER
+#include "catch.hpp"
+
+int main( int argc, char* const argv[] )
+{
+  // global setup...
+
+  int result = Catch::Session().run( argc, argv );
+
+  // global clean-up...
+
+  return result;
+}
+```
+
+## Amending the config
+
+If you still want Catch to process the command line, but you want to programatically tweak the config, you can do so in one of two ways:
+
+```c++
+#define CATCH_CONFIG_RUNNER
+#include "catch.hpp"
+
+int main( int argc, char* const argv[] )
+{
+  Catch::Session session; // There must be exactly once instance
+
+  // writing to session.configData() here sets defaults
+  // this is the preferred way to set them
+
+  int returnCode = session.applyCommandLine( argc, argv );
+  if( returnCode != 0 ) // Indicates a command line error
+  	return returnCode;
+
+  // writing to session.configData() or session.Config() here 
+  // overrides command line args
+  // only do this if you know you need to
+
+  return session.run();
+}
+```
+
+Take a look at the definitions of Config and ConfigData to see what you can do with them.
+
+To take full control of the config simply omit the call to ```applyCommandLine()```.
+
+## Adding your own command line options
+
+Catch embeds a powerful command line parser which you can also use to parse your own options out. This capability is still in active development but will be documented here when it is ready.
+
+---
+
+[Home](../README.md)

data/ext/snowcrash/test/vendor/Catch/docs/reference-index.md

@@ -0,0 +1,13 @@
+These are the currently documented areas of the framework. There is more to come.
+
+Before looking at this material be sure to read the [tutorial](tutorial.md)
+
+* [Command Line](command-line.md)
+* [Assertion Macros](assertions.md)
+* [Logging Macros](logging.md)
+* [Supplying your own main()](own-main.md)
+* [Test fixtures](test-fixtures.md)
+
+---
+
+[Home](../README.md)

data/ext/snowcrash/test/vendor/Catch/docs/test-fixtures.md

@@ -0,0 +1,32 @@
+Although Catch allows you to group tests together as sections within a test case, it can still convenient, sometimes, to group them using a more traditional test fixture. Catch fully supports this too. You define the test fixture as a simple structure:
+
+```c++
+class UniqueTestsFixture {
+  private:
+   static int uniqueID;
+  protected:
+   DBConnection conn;
+  public:
+   UniqueTestsFixture() : conn(DBConnection::createConnection("myDB")) {
+   }
+  protected:
+   int getID() {
+     return ++uniqueID;
+   }
+ };
+
+ int UniqueTestsFixture::uniqueID = 0;
+
+ TEST_CASE_METHOD(UniqueTestsFixture, "Create Employee/No Name", "[create]") {
+   REQUIRE_THROWS(conn.executeSQL("INSERT INTO employee (id, name) VALUES (?, ?)", getID(), ""));
+ }
+ TEST_CASE_METHOD(UniqueTestsFixture, "Create Employee/Normal", "[create]") {
+   REQUIRE(conn.executeSQL("INSERT INTO employee (id, name) VALUES (?, ?)", getID(), "Joe Bloggs"));
+ }
+```
+
+The two test cases here will create uniquely-named derived classes of UniqueTestsFixture and thus can access the `getID()` protected method and `conn` member variables. This ensures that both the test cases are able to create a DBConnection using the same method (DRY principle) and that any ID's created are unique such that the order that tests are executed does not matter.
+
+---
+
+[Home](../README.md)

data/ext/snowcrash/test/vendor/Catch/docs/tutorial.md

@@ -0,0 +1,100 @@
+# Getting Catch
+
+The simplest way to get Catch is to download the single header version from [http://builds.catch-lib.net](http://builds.catch-lib.net). Don't be put off by the word "builds" there. The single header is generated by merging a set of individual headers but it is still just normal source code in a header file.
+
+The full source for Catch, including test projects, documentation, and other things, is hosted on GitHub. [http://catch-lib.net](http://catch-lib.net) will redirect you there.
+
+
+## Where to put it?
+
+Catch is header only. All you need to do is drop the file(s) somewhere reachable from your project - either in some central location you can set your header search path to find, or directly into your project tree itself! This is a particularly good option for other Open-Source projects that want to use Catch for their test suite. See [this blog entry for more on that](http://www.levelofindirection.com/journal/2011/5/27/unit-testing-in-c-and-objective-c-just-got-ridiculously-easi-1.html). 
+
+The rest of this tutorial will assume that the Catch single-include header (or the include folder) is available unqualified - but you may need to prefix it with a folder name if necessary.
+
+# Writing tests
+
+Let's start with a really simple example. Say you have written a function to calculate factorials and now you want to test it (let's leave aside TDD for now). 
+
+```c++
+unsigned int Factorial( unsigned int number ) {
+    return number <= 1 ? number : Factorial(number-1)*number;
+}
+```
+
+To keep things simple we'll put everything in a single file.
+
+```c++
+#define CATCH_CONFIG_MAIN  // This tells Catch to provide a main() - only do this in one cpp file
+#include "catch.hpp"
+
+unsigned int Factorial( unsigned int number ) {
+    return number <= 1 ? number : Factorial(number-1)*number;
+}
+
+TEST_CASE( "Factorials are computed", "[factorial]" ) {
+    REQUIRE( Factorial(1) == 1 );
+    REQUIRE( Factorial(2) == 2 );
+    REQUIRE( Factorial(3) == 6 );
+    REQUIRE( Factorial(10) == 3628800 );
+}
+```
+
+This will compile to a complete executable which responds to [command line arguments](command-line.md). If you just run it with no arguments it will execute all test cases (in this case there is just one), report any failures, report a summary of how many tests passed and failed and return the number of failed tests (useful for if you just want a yes/ no answer to: "did it work").
+
+If you run this as written it will pass. Everything is good. Right?
+Well, there is still a bug here. In fact the first version of this tutorial I posted here genuinely had the bug in! So it's not completely contrived (thanks to Daryle Walker (```@CTMacUser```) for pointing this out).
+
+What is the bug? Well what is the factorial of zero?
+[The factorial of zero is one](http://mathforum.org/library/drmath/view/57128.html) - which is just one of those things you have to know (and remember!).
+
+Let's add that to the test case:
+
+```c++
+TEST_CASE( "Factorials are computed", "[factorial]" ) {
+    REQUIRE( Factorial(0) == 1 );
+    REQUIRE( Factorial(1) == 1 );
+    REQUIRE( Factorial(2) == 2 );
+    REQUIRE( Factorial(3) == 6 );
+    REQUIRE( Factorial(10) == 3628800 );
+}
+```
+
+Now we get a failure - something like:
+
+```
+Example.cpp:9: FAILED:
+  REQUIRE( Factorial(0) == 1 )
+with expansion:
+  0 == 1
+```
+
+Note that we get the actual return value of Factorial(0) printed for us (0) - even though we used a natural expression with the == operator. That let's us immediately see what the problem is.
+
+Let's change the factorial function to:
+
+```c++
+unsigned int Factorial( unsigned int number ) {
+  return number > 1 ? Factorial(number-1)*number : 1;
+}
+```
+
+Now all the tests pass.
+
+Of course there are still more issues to do deal with. For example we'll hit problems when the return value starts to exceed the range of an unsigned int. With factorials that can happen quite quickly. You might want to add tests for such cases and decide how to handle them. We'll stop short of doing that here.
+
+## What did we do here?
+
+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.
+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.
+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.
+
+## Next steps
+For more specific information see the [Reference pages](reference-index.md)
+
+
+---
+
+[Home](../README.md)