Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
This comment is hidden because it contains spoiler information about the solution
Yep - having the same problem myself
The description could use a little more detail, but PLEASE can you write some sensible failure messages for your tests - it took me ages to figure out that the
show_cart
method was responsible for checking whether the bill was too high, and that that was why the test was failing.Also - I have no idea where the
get_cash
method comes into it all. There's no test coverage for it, and I managed to implement a working solution without needing it at all.Apart from that - a nice kata. Always enjoy the ones that require proper OO design rather than fiddly little code-golf ones.
Am I being really dumb, or is there an issue with the local tests trying to actually connect to 'www.myblog.com'?
It doesn't seem to exist, and without some way of mocking the external calls, I can't work out what I'm supposed to do.
Nice Kata!
Good to see something that tests your skills as a structural programmer rather than just being good at maths.
I have no friggin idea why this is passing. Didn't mean to submit it, but I'm guessing there's either a problem with the test suite, or something screwed up on the server???
Why use the strange hash notation for extracting the answers? Just call the methods directly on the object, e.g.
rb.total_bet
instead ofrb[:total_bet]
Needs at least one more test - the case where the two closest balls are the same colour.
My code would fail this test, as it just looks at the first 2 distances, but doesn't take colour into account.
The explanation could use a little work. Maybe break down the methods into separate sections.
I also think that the fact that you have to save the
request_info
in an instance variable in theroute?
method is kinda ganky.This comment is hidden because it contains spoiler information about the solution
The description needs to explain how Easter is calculated.
I had to do quite a bit of googling which raised as many questions as it answered (what is a Pashel moon..? etc.)
Also - the tests are missing some edge cases. I got them all to pass by testing whether self was between March 22, and April 24 and was a sunday. This would pass for all sundays between those dates
May I suggest another sub-heading for the testing section?
The test output needs to give really clear messages as to why a test is failing. I've seen so many katas where the only feedback is 'expected to receive x, but received y'. This might be ok for some scenarios, but when the entire test suite is actually just a single spec and you only have the returned failure messages for each line, it tells you nothing about why your code is failing.
I'm a rubyist primarily, and the general rule is 'one assertion per spec'. That way, when something fails, you can see what element of the code you were checking for in the first place from the spec description. There are far to many where the test suite comprises of a single spec called something like 'it returns the correct answer', with about 15 assertions in it - all checking different things.