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.
got adapted to NUnit 4.
When I started migrating kata to NUnit 4 I wanted to disable the additional output, but i could not find a way. Then I found this article: https://docs.nunit.org/articles/nunit/Towards-NUnit4.html#improved-assert-result-messages and i looked into sources of NUnit 4 and i found no way to control the new output.
Bottom line is that the assertion expression is deliberately meant to use verbatim code and not values, because the goal behind it is easier identifiation of failed assertions in code. Runtime values are still presented as
actual
andexpected
. It works well in "real world" setup, but yeah, for CW can end up too verbose.After a conversation with an AI tool, I finally got the AI to admit this:
@hobovsky:
Is this possible to implement in the C# Codewars test setup?
In NUnit, you can indeed change the default behavior to show runtime values in assertion messages. This can be done by configuring NUnit to use more verbose output. Here's how you can do it:
In your test project, add or modify the file
nunit.runsettings
(or sometimes*.runsettings
).Add the following XML configuration:
The key setting here is
<DefaultAssertionMessageFormat>ShowDifferences</DefaultAssertionMessageFormat>
. This will make NUnit show the actual and expected values in the assertion messages by default.nunit.runsettings
file.After applying these settings, your assertion messages should include the runtime values by default, making debugging easier without needing to modify each individual assertion.
I find this new error message formatting in C# a bit ridiculous. Why can't it just give the runtime values instead :/
Using Assert.True in the ExampleTests on the collection of test cases makes the failure message unhelpful.
Refactoring so each test case gives it's own failure message would be nice.
I personally prefer TestCase or TestCaseSource for collections of tests.
This comment is hidden because it contains spoiler information about the solution
Nice kata. Reminds me to continue my series on kana (https://www.codewars.com/kata/kanakonverter-ii). Maybe later,...
I don't need to understand it now, my code was accepted, so this kata is finished;-)... Thanks for your reply and work!
Yeah, some people use that. And the IME accepts that. I just wanted to make this less hard as it is my first kata.
Is "jyu" even a thing? I've only seen "ju".
Yeah I was worried about whether people can understand what the description says. As I said, there won't be any
tsu
orchi
orshi
in there, so you don't need to replace it.I have added a
RandomTest
in the test cases. Hopefully you can understand what I mean by reading that. I don't know how can I word it better, without giving too much away.For me your description (i read nothing else) was "hard" to understand in details and i don't know, if my solutions is completely correct or if some edge- cases are missing in your tests. I never heard about "kanas", so i "guessed some special cases" - perhaps you can see it in my code;-)...
... deleted this message, codewars error (duplicate message)...
By the way, welcome to codewars, just saw that this is your first kata, so generally well done:-)!