Kata

hi, thanks for pointing out issues. is it better now?

Good effort, but unfortunately you introduced new problems at the same time... ;)

• plz select python 3.6 as the default language version, in the edit panel (I forgot previously)
• new part of the description: You don't have to include "\n" in the output string -> x/ Na, that's asbolutely bad. The user should be able to print his output and that it looks like the expected figure. Change that, plz.
• about the assertion/sample tests: the addtiionnal error message is a good idea... when displayed in the console. Other wise, it's totally unreadable in the sample tests part. I'd suggest the following:
  • remove all additionnal message
  • build your own test funcion in which you pass the actual and expected results.
  • inside the function, you print the strings to the console first (with some space/legends around)
  • then you do the assertion
  • ofc, you put a limit size on the string, for displaying them to the console (otherwise you'll hit the max buffer limit error) => print the strings only if, say, their length is shorter than 200-250, maybe? (maybe more...)

other than that, it looks fine, I'd say. Ah, one last thing: Notice that the glass has been filled by defect for non native speaker, this "defect" is rather obscur. I find that annoying considering this is actually hidding one of the requirements...

D: ok i try to fix;

• instead the user should include "\n" ?
• something like this?

  if my_test(user_function(), expected):
       test.pass_()
  

• do you mean that i should explain more what "defect" means?

• string: yes, join each line with a \n
• tst function:

def doTest(actual,expected):      # using python 3.6
    if len(expected) < ...:
        print(f'''
Expected:
{expected}

Actual:
{actual}''')
    Test.assert_equals(actual,expected)

• defect: that or use another wording, maybe. As you prefer.

ok, thanks should be ok now

almost:

w = 8
h = 10
prg = 33%

Expected :

*      *
*      *
*      *
*      *
*      *
*      *
*      *
*//////*
*\\\\\\*
********

Actual :

*      *
*      *
*      *
*      *
*      *
*      *
*      *
*//////*
*\\\\\\*
********
'*      *\n*      *\n*      *\n*      *\n*      *\n*      *\n*      *\n*//////*\n*\\\\\\\\\\\\*\n********' should equal '*      *\n*      *\n*      *\n*      *\n*      *\n*      *\n*      *\n*//////*\n*\\\\\\\\\\\\*\n********\n'

• the display is good, globally
• description:
  • that example must be short so that it's at least a bit usable...
  • the example of out must be actual code string, not formatted string (=> either put 4 spaces at the beginning of the line, or put backticks around it / on second thoughts, having both versions, meaning formatted/unformatted might be a good idea)
• the expected result is... feels kind of "wrong": you chose to put an "extra" \nat the end of the string... That's described (even if for now there is no visible code string showing that), so it's actually ok. But it really feels like practice from another era, especially when you use something like python... Imo you should remove that one.
• the assertion process is a bit weird, for now. You should update it to something like this

def doTest(get_glass, a,b,c, expected):
    actual = get_glass(a,b,c)
    ...
    
    

do_test(get_glass, 3, 3, 50, "* *\n"    \
                             "*\\*\n"   \
                             "***\n")

This way, the design is more reasonnable and more readable (and it avoids duplicated code/data)

Note: you could add another note to the description, that the actual and expected results will be printed to the console for the user, unless the size of the output is too large.

• then i change the last example in description to something smaller ? like 5-6 height
• how could i deal with those extra "\n" ?
• test function and additional note on description : ok i will fix

changed description and test function. added f-strings when printing

do you mind if I edit your kata?

not a problem

done. See if it suites your mind too.

Note: I've changed the requirements and the description about the final "new line" (I removed it)

ok, it's better now :o thanks for help!

you're welcome

oh, btw, for your next kata: always keep the sample tests at the beginning of the test suite (only the "test cases" part is executed in an attempt)

ok, thanks :)