I don't know how to do that.

There is a very seirous problem with this solution. While it works in all cases, I just want to points out that n.abs always returns something truthy. So you'll always get the first branch of your conditional which just happened to do the right thing.

You're quite right. This is some code I tried on many katas on codewars to see how many of them I can solve with a generic solution like this. I create an object and I'm changing the eigenclass of that object by overwriting the == method. Then decompose(y) == x will return true or any values x and y. Another even more generic solution included the use of method_missing to ensure that every method called on the object also returned an equality object. This ensured that even testing for derived values like the length of an array would not fail this solution.

The point why this actually works isn't so much seen here though. Any test framework has to check for equality at some point like this:

if actual == expected
  test_is_passing
else
  test_is_failing
end

So this solution just fakes an always passing test (see https://github.com/Codewars/kata-test-framework-ruby/blob/master/framework.rb at line 147). There is no way to prevent that kind of solution, but some way to make it harder. I think there should be some tests using Test.expect(expected == actual) then you can't simply modify the comparison of the object you return, but you'd have to monkey patch the class of what is expected. When the kata would test for several values like length of the array, specific elements, iteration over it, and such it would be a major hazzle figuring out everything.

Just a little reminder that this solution is of course a fake. It doesn't solve the actual problem, it just demonstrates that green tests aren't a good metric, because no actual behavior might be implemented (doesn't have to be obvious like here though).

I enjoyed this kata and translated it to ruby. Since it's my first translation I'm not sure about the process. I've seen a couple of posts about translated katas, so I'm doing the same.

I've gone off track from the return a function thing to make it feel more natural in ruby.

I enjoyed this kata, thank you very much.

It's a cheap solution to many katas I was figuring out for a while. Basically what happens:

The tests check the return value of the method for different parameters against a test result. E.g. assert_equals(add(2, 2), 4) checks whether add(2, 2) == 4 and gives error messages and stuff if the comaprison fails. In ruby the comparison is equal to add(2, 2).==(4) thus the equality method is called on the return value of add(2, 2) if add() now eturn an object that always return true when it's == method is called assert_equals will always pass.

My solution accomplish this by manipulating the eigenclass of the object.

I would like to see a change from Test.expect to Test.assert_equals to include a nicer error message. Also the user facing test miss the case of multiple streaks.

I had a viable solution that produced another ordering then the tests expected, which is neither specified nor could I guess a propper ordering by myself to reproduce the test results.

I would like to see a test for empty comments, because my solution should fail for lines like "/**/".

And I suggest to change the test cases to also have comments within comments, so that "/* some text /**/ other*/" becomes "" instead of "other*/" which I think most of the current solutions would produce.

I would like to see more specific test cases. Sometimes I was sitting there trying to analyze a failing test just to notice that it was actually some other test that failed. I think it's best practice to have one assertion per test. Thus I would like to see methods like:

@Test
public void testWithNegativeNumbers() {
assertEquals("-1/2", Fraction.new(1, -2));
}

and so on. Also I think a fraction class like this would benefit of methods to compare two fractions. Maybe that's too annoyingly borring but I already thought that after the add() method.

I think I found a missing test case: My solution passes all test, but it should fail on input where the boundaries of the matrix come into play. My solution should fail for a test like find(new int[][]{{0, 1},{2,3}}, 2) because it doesn't check whether it reached the end of the current row.

This also holds true for the harder variant of this kata.

I think you're right, but it still feels confusing that the output in the tests differs from the input. But it's a very small issue so I don't bother you anymore. (:

Wow. One of the finest katas I've seen so far. So I'm really sorry to bother with this fine kata and it's a really small complaint.

The descriptions says the format of the month is mmyyyy while I think the ruby tests actually do mm/yyyy.

The ruby version has some issues from what I guess is a poor translation of a python kata:

• Several mentions of None should be translated to nil.
• One test doesn't even work. it reads: x is not nil which is not proper ruby. Should be changed to x != nil or better !x.nil?