Update unit tests draw.ellipse, add unit tests draw.(aa)line(s)

[amosbastian]

This pull request contains the following:

Ellipse

I updated the draw.ellipse unit test so that it now also includes a test that checks if at least two sides of an ellipse, that has a width and height that is 1 pixel smaller than the surface, is touching the surface's border.

It also cleans up the code slightly, including a better way of retrieving the border's values and adds reusability in the form of additional functions.

See: #233

Lines

It also adds unit tests for draw.aaline, draw.line, draw.aalines and draw.lines.

For draw.aaline and draw.line it now draws a line of differing colours on all types of surfaces and checks if the colour stays the same at position (0, 0). There is also a test that checks if the line contains any gaps, as I noticed aaline(s) sometimes does (or is not drawn at all when close to a surface's border).

The same is done for draw.aalines and draw.lines, except these tests draw a line around the border of the given surface then check if all pixels are of the given colour, or if they contain gaps.

See: #395

[e1000]

Personnally, I have some issues about line_is_color ,line_has_gaps and lines_have_gaps :

1. all repeat the if line_type == "aalines": , hence it seems to be repeated code
2. it mixes doing something and testing something ; so imho, that's bit confusing, it looks bit as you were testing your own test functions ;)
3. line_has_gaps and lines_have_gaps : with a quick look I can not understand what the gaps are? And why does the equalities at the end mean that there is a gap (or are gaps) ?

So , for me, these helper functions contain a bit too much logic / factorisation ?

[illume]

@e1000 some good suggestions. Thank you.

1. line_is_color and friends could be improved by taking a draw function as the argument instead of a string. Maybe call the argument draw_line and then pass in draw.line or draw.aaline.

2. Then when using line_is_color, the draw_line can be just another parameter in the one test function(test_line_color). This would reduce the number of tests you have too. Also the implementation of line_is_color could be moved inside that one test(because now there are not two). So it would be easier for the person reading it to see what it is doing. Because then line_is_color and test_line_color would fit in one screen.

These two changes would reduce the amount of repeated code (DRY) https://en.wikipedia.org/wiki/Don%27t_repeat_yourself And I think it would bring related test code closer together in the file, making it easier to understand.

3. Yeah, a different explanation of what gaps are would improve this. It would also help readers of the code to put a link to the issue in the docstring. So they could see the image of the issue themselves.

[illume]

On Travis CI tests I see this error come up:

======================================================================
ERROR: test_line (pygame.tests.draw_test.DrawModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/virtualenv/python2.7.14/lib/python2.7/site-packages/pygame-1.9.5.dev0-py2.7-linux-x86_64.egg/pygame/tests/draw_test.py", line 312, in setUp
    self.surf = pygame.Surface(self.surf_size, pygame.SRCALPHA)
ValueError: no standard masks exist for given bitdepth with alpha

So maybe we need to specify the bit depth for when the tests run like this.

This error is raised when the depth is 8, but it works for depth 16, and depth 32.

>>> pygame.Surface((10,10), pygame.SRCALPHA, 8)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: no standard masks exist for given bitdepth with alpha

[amosbastian]

Thanks for the feedback @e1000 @illume, I just refactored everything and updated the lines_set_up() function so it creates surfaces of an even width/height and odd width/height, with differing depths (16 and 32). If there is anything else left to be improved then please let me know.

[illume]

Wonderful! 🎈 🎉