Looks good, but I think you should also add the full coverage tests where every single combination of input is tested as well (exam — from 0 to 100; and projects from 0 to 15 or 20).
Also random tests are broken, since you generate exam and projects only once, before the loop with all test checks...
The reason I did not include these in C# is to be forward compatible with future language versions. Unlike contextual keywords, it is unlikely new keywords will de added to the language.
C# translation does not include contextual keywords. I would be in favour of doing it the same for Java.
Should be up to discussion though.
If you want to keep the separation I would replace the class in Preloaded by a record though.
The other langauges (as far as I have checked) are using a "missing a keyword for (informal description of the use case)" and that must also be included in this translation. You should have a chance to solve this kata without just looking up the keywords.
Remove the last 2 lines of the code block in the description and add to the plain text description
You can implement the random string generator as (repeatedly len #(rand-nth "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"), or something similar with rand-nth
I have difficulty reading LISP, but are you generating lists of completely random names for the random tests? Those would be very unlikely to include repeats.
You should be generating lists of names picked randomly from a limited list, the way it's done in JS and Haskell ( I don't know how the C# original does it. I hope that doesn't generate completely random name lists either ).
test/CalculateParityBitSpec.hs:18:105: error:
• Couldn't match expected type ‘Int’ with actual type ‘Word’
• In the third argument of ‘assertEqual’, namely
‘(checkParity parity string)’
In a stmt of a 'do' block:
assertEqual
("checkParity " <> show parity <> " " <> show string)
(refCheckParity parity string) (checkParity parity string)
In the expression:
do assertEqual
("checkParity " <> show parity <> " " <> show string)
(refCheckParity parity string) (checkParity parity string)
|
18 | assertEqual ("checkParity " <> show parity <> " " <> show string) (refCheckParity parity string) (checkParity parity string)
|
^^^^^^^^^^^^^^^^^^^^^^^^^
Clojure translation
Clojure Translation
Looks good, but I think you should also add the full coverage tests where every single combination of input is tested as well (exam — from 0 to 100; and projects from 0 to 15 or 20).
Also random tests are broken, since you generate
examandprojectsonly once, before the loop with all test checks...The reason I did not include these in C# is to be forward compatible with future language versions. Unlike contextual keywords, it is unlikely new keywords will de added to the language.
C# translation does not include contextual keywords. I would be in favour of doing it the same for Java.
Should be up to discussion though.
If you want to keep the separation I would replace the class in Preloaded by a
recordthough.The other langauges (as far as I have checked) are using a "missing a keyword for (informal description of the use case)" and that must also be included in this translation. You should have a chance to solve this kata without just looking up the keywords.
A couple optimizations are warranted:
(repeatedly len #(rand-nth "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"), or something similar withrand-nthD:
Good point. This now uses a list of candidate names to generate an input list of up to 100 names. Thank you!
I have difficulty reading LISP, but are you generating lists of completely random names for the random tests? Those would be very unlikely to include repeats.
You should be generating lists of names picked randomly from a limited list, the way it's done in JS and Haskell ( I don't know how the C# original does it. I hope that doesn't generate completely random name lists either ).
Type issue in the test suite?
test/CalculateParityBitSpec.hs:18:105: error:
• Couldn't match expected type ‘Int’ with actual type ‘Word’
• In the third argument of ‘assertEqual’, namely
‘(checkParity parity string)’
In a stmt of a 'do' block:
assertEqual
("checkParity " <> show parity <> " " <> show string)
(refCheckParity parity string) (checkParity parity string)
In the expression:
do assertEqual
("checkParity " <> show parity <> " " <> show string)
(refCheckParity parity string) (checkParity parity string)
|
18 | assertEqual ("checkParity " <> show parity <> " " <> show string) (refCheckParity parity string) (checkParity parity string)
|
^^^^^^^^^^^^^^^^^^^^^^^^^
Ashamed that I didn't realize it was this simple...
The Scala function should return List[String], not List[String, String]