Kata

Hey @LS2008 - no worries! Well, just to be clear I'm not employed by Codewars or anything like that - I volunteer as a mender, which just means helping maintain some of the content.

To answer your question; Codewars is run by https://www.qualified.io/ who do indeed provide the kind of services for schools/educational institutions that you seem to be interested in.

Several of their senior employees are in the Codewars Discord (the link is in sidebar on the left of your screen), so your best bet is to contact them there - you will find that there is a channel called #codewars which is designed for this purpose - and you can explain your requirements/enquiry and get a direct answer or setup a Zoom call/email discussion.

Hope that helps!

Thanks @benjaminzwhite, that really helps! I will go and have a check.

Hi @Jam14man - thank you for the kind words and for solving; you are right, there was a small problem with the data types used in the random tests, which made your approach fail.

Since you're the first person to try this kind of approach, thank you very much for noticing!

I have fixed it now and your approach should not cause the tests to fail due to TypeError.

However, you may find that your approach times out as it is quite inefficient. So you may still need to find a new solution.

Ok, thanks. Then I will try again. :)

@eloise_ Thanks for the feedback! Glad you liked it; it's my first submission, so it encourages me to make more.

Following solution:

def interweave(ineqs, ints):
    return "<>"

results in:

Traceback (most recent call last):
  File "/workspace/default/src/codewars-test/codewars_test/test_framework.py", line 111, in wrapper
    func()
  File "tests.py", line 10, in test_evals_to_true
    test.assert_equals(eval(user_sol), True)
  File "<string>", line 1
    <>
     ^
SyntaxError: unexpected EOF while parsing

and

Traceback (most recent call last):
  File "/workspace/default/src/codewars-test/codewars_test/test_framework.py", line 111, in wrapper
    func()
  File "tests.py", line 36, in test_same_input_ints
    ints_in_user_sol = sorted( [int(n) for n in nums_in_user_sol.split(' ')] )
  File "tests.py", line 36, in <listcomp>
    ints_in_user_sol = sorted( [int(n) for n in nums_in_user_sol.split(' ')] )
ValueError: invalid literal for int() with base 10: ''

@benjaminzwhite: don't rely on eval, actually test the string by parsing it

@Blind4Basics : Thanks for the feedback, I've just started working through @hobovsky 's useful comments and will follow your advice! It's my first kata, I'm using it to understand the testing framework and following all the codewars documentation. T

wouldn't that be simpler if the output was just an array of integers in appropriate order to satisfy the "query"? That would be way simpler to test on your side, and avoid the string conversion hassle on the user side.

@Blind4Basics ah that's a really good idea; maybe for my first experience with kata testing it would be a nice simplification. I'm going to try a redesign and see if that's easier.

@Blind4Basics - Hi, I've redesigned the kata so it now asks for user to return an array of integers in order, as you suggested.

I've also reorganized the tests a bit more, and implemented fully random testing for the random tests.

However, can you help with the other issue: I still don't understand how to solve @hobovsky 's comment about returning unexpected values: how can I handle that with the test cases?

To see how other people resolve this issue, I tried on a few other peoples' katas to return deliberately incorrect values/types and I find that I get the same kind of error messages on their katas.

Also, am I allowed to mark Issues as resolved or is that only for mods while the kata is still in Beta?

Thanks for any help, and please let me know if I can do anything better (still a newbie).

The thing is that in dynamically typed languages, tests have to be realy thorough to detect and gracefully react to various mistakes, and generally kata authors and translators are not bothered with such lame practices - that's why you do not see it in most of kata. I am also not that picky to bother you with tests of, for example, type of returned value whether it's definitely an array and not a string or Person or something. I would have to write such test at work, but I can pass it for a kata.

However, what is good to handle, are things like None or size of an array, to make sure that solutions like pass or return [] or some other WIP solutions still fail gracefuly and dont crash because tests do something like

actual = solution(input)
asser.equals(10, actual[0]) # crashes badly if actual is None, or [ ], or other incorrect, but probable value