Ad
  • Custom User Avatar
  • Custom User Avatar

    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 returning None), or some other value of unexpected type. I would recommend making an assertion on the type before attempting to format the actual (but still presenting history and expected as formatted).

  • Custom User Avatar

    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.

  • Custom User Avatar

    I would have to see to know exactly, but you can try using <:LF:> marker insteaf of \n newline.

  • Custom User Avatar

    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.

  • Custom User Avatar

    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.)

  • Custom User Avatar

    Fixed all except the testing titles, still a little bit confused on those.

  • Custom User Avatar

    Resolved

  • Custom User Avatar

    Resolved

  • Custom User Avatar

    Resolved

  • Custom User Avatar

    Description does not restrict the range of dates in history. Technically they can be further than current (for example, if users change their system clock), and in this case it's undefined how they should be handled.

  • Custom User Avatar

    Random tests pass in strings in current instead of datetime, which is inconsistent to the sample tests.

    If sorted by date/time, return a dictionary containing keys that are "Today", "Yesterday", "This Week", "This Month", "This Year", and "Past a Year" (if there are entries within these time periods) and corresponding values that contain a list of entries within these time periods (sorted by date and time)

    Sample tests do not have a test case that demonstrates value besides This Year and Past a Year. Random tests only sometimes go up to This 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.

  • Custom User Avatar

    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.

  • Custom User Avatar

    The history list should be a list (and the user function should receive a copy).

  • Custom User Avatar
    • Python: function name should be snake_case
    • "00:00" with no leading zeros for the hour but many times have leading zeroes.
  • Loading more items...