Merge pull request #21 from bkaestner/issue-20-solutions

Add information on how to handle reference solutions

Author: bkaestner

rules/0100-Writing-a-kata.md

@@ -144,14 +144,14 @@ possible, use the proper type and avoid string, unless it leads to convoluted co
 
 Use the preloaded section only for helpers or constraints
 ---------------------------------------------------------
-While it might seem tempting to put your solution into the preloaded code
-section, don't. Some languages provide reflection or similar means to check your
-preloaded code, which enables a user to cheat rather easily.
-
-Also, if you're using a dynamic language like Python, JavaScript or Ruby, keep
-in mind that the user can change `Math.random` or similar features unless you
-use `Object.freeze` or similar. Java, Haskell, C# and potential other statically
-typed languages don't share this problem.
+The preloaded code is both usable by you and the user. It's the perfect place to
+put helpers or data structures that the user should use, or to freeze objects in
+dynamic languages.
+
+However, __never__ put your solution into the preloaded code! Some languages
+provide reflection or similar means to check your preloaded code, which enables
+a user to cheat rather easily. Instead, put your solution into a local scope
+(see "Hide your solution").
 
 
 Provide helpers for tasks that are dull

rules/0120-Tests.md

@@ -96,6 +96,38 @@ This is usually the hard part of creating random tests. After all, creating
 sufficient random input is most often harder than creating the kata itself.
 But it is worth every honour.
 
+### Hide your solution
+If you use random tests, make sure to hide your solution. In Java or C#, this
+includes making your function `private`. Haskell doesn't allow mutual imports,
+so the user cannot import the tests either way. However, in dynamic languages,
+one can sometimes simply use `solve = solution`.
+
+You can prevent this kind of cheating if you
+
+- add static tests (not only random ones),
+- move your solution into a local scope.
+
+The first one is obvious. The second one can be realized if you don't provide
+a `solution` with the same interface, but instead a `testAgainstSolution`:
+
+```javascript
+// bad!
+var solution = function(a, b){
+  // ...
+}
+
+// better
+var testFunction = function(a,b){
+  var solution = function(a, b) {
+    // ...
+  }
+  Test.assertEquals(userFunc(a,b), solution(a,b));
+}
+```
+There are more creative ways to hide/store the function, but that's one way
+at least. Note that all dynamic languages on Codewars (Ruby, Python, CS, JS)
+support this kind of local scopes.
+
 ### Always have some example tests
 
 Unless you're creating a puzzle where the user has to find *the answer*,