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.
Implemented.
I think presentation is not bad now. What still could be improved is that tests crash badly when the solution gets types wrong, and returns a list instead of dict or vice versa, or
None
(which can happen when some branch in the logic is missing and the execution falls out of the function, implicitly returningNone
), or some other value of unexpected type. I would recommend making an assertion on the type before attempting to format theactual
(but still presentinghistory
andexpected
as formatted).After lots of tweaking and tuning, I got a unittest format that I'm happy with, please take a look at it and give it some feedback when you get the chance. The marker instead of newline worked, so thanks for that.
I would have to see to know exactly, but you can try using
<:LF:>
marker insteaf of\n
newline.Thats awesome, thanks for taking the time to explain and code that up. I started implementing and formatting it today but will have to finish tomorrow because I do not want to publish a half tab half messy assertion. For some reason whenever I try to do \n in the logging it makes a new log space instead of a new line. Any insight? Thanks again.
Here you have example of assertion messages instead of titles: https://www.codewars.com/kumite/66c513932287786e6a8486a6?sel=66c513932287786e6a8486a6 (it's just an example, you can work on improvements to the formatting if you want).
Here is an example of feedback with tab panels: https://www.codewars.com/kumite/66c513932287786e6a8486a6?sel=66c516d4d3f71cbc8ec3b725 (again, just an example, you'd have to work out the details of presentation of dicts vs lists etc.)
Fixed all except the testing titles, still a little bit confused on those.
Resolved
Resolved
Resolved
Description does not restrict the range of dates in
history
. Technically they can be further thancurrent
(for example, if users change their system clock), and in this case it's undefined how they should be handled.Random tests pass in strings in
current
instead of datetime, which is inconsistent to the sample tests.Sample tests do not have a test case that demonstrates value besides
This Year
andPast a Year
. Random tests only sometimes go up toThis Month
. The test coverage is inadequate.A related issue: there should be fixed tests in actual test code too. It should be a superset of the sample tests.
Presenting inputs is (almost) always a good thing, I fully agree. But there is more than one way to present them, not just with titles of
@it
. I will try to prepare examples for you with two other possibilities: all random tests collapsed to a single@it
and presenting inputs euther with an assertion message, or with special type of output tabs supported by CW test panel. You will judge which approach you like the most.The history list should be a list (and the user function should receive a copy).
Loading more items...