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.
Done.
Done.
Case not actually added to most languages as far as I can see.
I don't think that requirement should exist to begin with. The original kata language is js so it's probably the usual fascination with coercion. If original language was java it would have been a method in a class instead.
I've gone ahead and made it
"Failed for: $(repr(word))"
, which I presume you meant. This now prints with quotes around the input.Could you clarify why you would like to annotate the function types? From everything I've seen, it is not idomatic in Julia to do that for every function. Usually it's only done when there is multiple dispatch or performance concerns, and I don't see either of those in this kata.
Why include types in a 7 kyu?
Fixed the
facts
\context
issue.repr(word)
==$word
in JuliaDone.
approved
context
issue.The assertion messages only show on failure, so I've included the input provided for the random tests so users can see the input explicitly on failure. This information was already present in the fixed tests due to how they are reported. Let me know if there is something else more useful.
Since calls to FactCheck are so slow, I usually try to avoid going over 100 tests (hence the initial 55 random tests). With the full 100 the full test suite is now running at 7000-8000ms (up from ~5000ms). However, I could change it so not every random test involves a call to
@fact
and quits on the first failure. Not sure which is preferable.I think I did them all, so I believe I've addressed all the issues.
I republished, even though I haven't done the “assertion messages in quotes” yet. I was working in my office and I didn't want to lose anything before I went home.
To clarify, do you mean the following?
Instead of:
Test Failed
Square was A8
Expected: < "A1", "A2", "A3", "A4", "A5", "A6", "A7", "B7", "B8", "C6", "C8", "D5", "D8", "E4", "E8", "F3", "F8", "G2", "G8", "H1", "H8" >
But was: null
you prefer this:
Test Failed
"Square was A8"
Expected: < "A1", "A2", "A3", "A4", "A5", "A6", "A7", "B7", "B8", "C6", "C8", "D5", "D8", "E4", "E8", "F3", "F8", "G2", "G8", "H1", "H8" >
But was: null
By the way, I'm curious how this old translation got your attention.
I haven't used C# in a long time (this is a translation from 2 years ago), so I might be unaware of this, but does C# allow variable access outside of the function's scope, since that's the only reason that I could think of for this change to be necessary. Not to mention, adding the private modifier directly to the variable causes a compile time error, since (at least from what I can tell) you can't add access modifiers to variables inside a function's scope. Some further clarification would be gratefully appreciated.
Changed
Added the input into the assertion message, NUnit handles showing the actual and expected
Rust fork with random tests.
fork
though it looked like the description was only different by a single trailing newline...
Loading more items...