What failures are you getting? I cannot see your solution so I've no way to know what it is happening unfortunately.

I think I have fixed this now.

OK, I am pretty sure the tests for JS are doing that already.

.

Do you have some detail on the test results you're getting? What's failing specifically?

I agree that where a random is involved that it is perfectly valid (however unlikely) for all results to be same, all uppercase and all lowercase. What I am unclear on is how this can be tested any better? That's what I am interested to hear more about. Is there something you did in your tests that I am missing or not understand this attempts to mitigate this issues?

I am not keen on having RandomCaseTester in preloaded coded because it means that the implementer cannot see what it is doing from the Sample Test Cases.

The JavaScript tests are defined as:

let v = [
  "Lorem ipsum dolor sit amet, consectetur adipiscing elit",
  "Donec eleifend cursus lobortis",
  "THIS IS AN ALL CAPS STRING",
  "this is an all lower string"
];

for(var i in v) {
  var r = randomCase(v[i]);
  Test.assertEquals(r.toLowerCase(), v[i].toLowerCase());
  Test.assertNotEquals(r, v[i]);
  Test.assertNotEquals(r, v[i].toUpperCase());
  Test.assertNotEquals(r, v[i].toLowerCase());
}

which keeps it nice and simple.

Please also ensure that you've covered all the cases that the JS test cases encompass:

Test.expect("randomCase", "Random case function expected");

function getRandomIntInclusive(min, max) {
  return Math.floor(Math.random() * (max - min + 1)) + min;
}

function randomString(length) {
  var r = "";
  if(length == null) length = 50;
  for(var i = 0; i <= length; i++) {
    r += String.fromCharCode(getRandomIntInclusive(65, 90));
    r += String.fromCharCode(getRandomIntInclusive(97, 122));
  }
  return r;
}

let a = [
  "These guidelines are designed to be compatible with Joe Celko’s SQL Programming Style book",
  "much harder with a physical book.",
  "This guide is a little more opinionated in some areas and in others a little more relaxed",
  "—such as unnecessary quoting or parentheses or WHERE clauses that can otherwise be derived.",
  "Object oriented design principles should not be applied to SQL or database structures.",
  "collective name or, less ideally, a plural form. For example (in order of preference) staff and employees",
  "THIS IS AN ALL CAPS STRING",
  "this is an all lower string"
];

var b = [];

for(var k = 0; k < 100; k++) {
  b.push(randomString(k + 25));
}

let v = a.concat(b);

for(var i in v) {
  var r = randomCase(v[i]);
  Test.assertEquals(r.toLowerCase(), v[i].toLowerCase());
  Test.assertNotEquals(r, v[i]);
  Test.assertNotEquals(r, v[i].toUpperCase());
  Test.assertNotEquals(r, v[i].toLowerCase());
  let mixedCases = function(){
      l = r.split("").filter(function(x) {
        return x === x.toLowerCase();
      });
      return l.length !== 0 &&
             l.length < r.length &&
             l.length > r.length / 5;
    };
  Test.expect( // make sure we've a good mix of cases
    mixedCases(), 
    "Must have a mix of upper and lower case letters"
  );
  let randomCheck = function(){
      var track = [];
      for(var j = 0; j < 150; j++) {
        track.push(randomCase(v[i]) === r);
      }
      return track.filter(function(x) {
        return x;
      }).length < 10;
    };
  Test.expect( // make sure we're not getting the same mix all
    // the time - must be random to some extent
    randomCheck(), 
    "Must have a mix of upper and lower case letters"
  );
}

Phone numbers may or may not have a leading zero, contain formatting for country or area codes and additional information such as extension numbers etc.

031 753 776
039324892
+850 (0195) 1 823 167
+850 (079) 907 489 (ext. 2582)

Whereas a credit card number can be a string or when stripped of whitespace an integer.

4012888888881881
348282246310005
6012 9999 9999 9999
5305 1051 0510 5106

This is also one little hurdle to throw into the kata to make it a touch more difficult/require some thought.

I cannot merge this one as the description has now diverged - please could you update your kumite with the new description from the master kata?

Also please could you add two more tests for visa? This is from the JS tests:

Test.assertNotEquals(getIssuer(41111111111111), 'VISA');
Test.assertNotEquals(getIssuer(411111111111111), 'VISA');

This prevents invalid regex (\d{12,15} - should be (\d{12}|\d{15})) from matching.

You're right - that was an oversight in the tests. I've now added a couple tests to all the languages to prevent this from passing.

The solution in Java was even exploiting this!

Was a real PITA as I had to republish after changing each language - if I did them all at once it kept coming back saying the server had timed out!

Anyway should be fixed now for all langs.

@GiacomoSorbi - I cannot see the difference between what you're doing in Ruby and Crystal versus the tests mentioned above - they're both going to fail @dinglemouse tossing as far as I can see. Am I missing something?

Weird I didn't get notified about the crystal one so thanks for the link. Is there some way to see all the kumite against a given kata?

@dinglemouse Meh. It's open to collaborators, so please feel free to do better than me.