Added "What did we do here?" section

Updated Getting the source code (markdown)

Tutorial.md

@@ -58,4 +58,13 @@ Your compiler will likely warn you about that last value (for 32 bit ints), but
 
 Note that we get the actual return value of Factorial(13) printed for us - even though we used a natural expression with the == operator.
 
-If we change the factorial function to take and return unsigned long instead (assuming 64 bit long) we should see this particular bug go away. Of course we have just pushed it out to a higher number, but it's up to the logic of your code to decide how to handle the overflow.
+If we change the factorial function to take and return unsigned long instead (assuming 64 bit long) we should see this particular bug go away. Of course we have just pushed it out to a higher number, but it's up to the logic of your code to decide how to handle the overflow.
+
+## 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 #include one header and we got everything - even an implementation of main() that will respond to command line arguments. You can only do this in one implementation file, for (hopefully) obvious reasons. Once you have more than one file with unit tests in you'll want to just #include "catch.hpp" instead. Usually it's a good idea to have a dedicated implementation file that just #include's "catch_with_main.hpp" as your entry point. You can also provide your own implementation of main and drive Catch yourself.
+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.