• A few suggestions:

    • Include the static tests in the full test suite, not just the sample test suite - your code does not guarantee that empty strings will be tested and so invalid solutions could slip through by trying to run the tests enough times
    • It might improve the user experience to have the static tests each as a separate [Test] method - that way it is a bit clearer which test is failing
    • Add a fixed test with null as the argument - also consider including null in your array of names in the random tests
    • Rename test method from MyTest, e.g. RandomTests
    • Whilst not absolutely necessary, remove the (now redundant) TODO comments knocking around
    • Calling [...].Substring(...).ToString() is a redundant call to [...].ToString() - Subtring(...) returns a string.
    • The reference solution isn't ideal - try/catch shouldn't normally be used for flow control, what errors are you expecting to catch here? Rather than lazily use try/catch for edge cases, think what they could be and explicitly guard against them / use flow control to deal with them
  • Thanks. I was dumb to not notice that... So now I'm passing the sample tests, but failing some random ones. Could be related to @FArekussu issue raised above, IDK.

  • most insignificant digits

    It's "least significant bits".

  • RGB888 = 4c6a02
    R = 4c (hex) = 01001100 (bin)
    G = 6a (hex) = 01101010 (bin)
    B = 02 (hex) = 00000010 (bin)
    BGR555 = 000000110101001 (bin) = 425 (dec) = 01a9 (hex)
    
    Expected: "001a"
    But was:  "a901"
    

    Either the reference solution is wrong, or some information is missing from the description.

    Edit: I've looked at your solution, and it is indeed incorrect.

  • Since it's BGR555, you need to put the blue (00100) first and then green then red.

  • Could you please explain then:

    Assert.AreEqual("b110", Kata.BGR555("8b2c22"));
    
    8b => 1000 1011 (take 10001)
    2c => 0010 1100 (take 00101)
    22 => 0010 0010 (take 00100)
    
    Together: 10001 + 00101 + 00100 == 100010010100100 (binary) == 44a4 (hex) == a444 (little-endian)
    

    Where am I going wrong?

  • i have to make another post to make it resolved because i forgot

  • Fixed!

  • Should each hex character be converted to 4-digit binary representation, or should it be the whole hex pair, padded left to 8 digits?

  • You will need to add extra zeroes to the beginning so that the number reaches 8 digits.

  • Loading more items...