Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

Python Python Testing First Steps With Testing Writing and Running Doctests

How could the player possibly move up? Python Testing

In the video "Writing and Running Doctests" Kenneth Love tests the get_moves function inside of the dd_game file. In the test script the game dimensions are defined as (2,2) and the starting position is (0,2). When writing the test in the console, and running get moves, possible moves returned include: right, up, or down.

Can someone please explain, If the character is already in the top left corner (0, 2), how can it possibly move up any further

Matthew Rigdon
Matthew Rigdon
8,223 Points

It isn't possible for the character to move up based on those specifications. To be more specific as to why there is a possibility to move up, we would have to see code. Was this in Kenneth Love's demo video, or your own experimentation?

Kenneth Love begins discussing the get moves function right around the 6:30 mark in this video. https://teamtreehouse.com/library/python-testing/first-steps-with-testing/writing-and-running-doctests

3 Answers

Kenneth Love
STAFF
Kenneth Love
Treehouse Guest Teacher

So, before I did this course, I quickly rewrote some code from Python Collections. I had swapped traditional X and Y coordinates and had them as, effectively, Y and X coordinates. Anyway, I probably just missed a bit of change in the get_moves function and didn't change it, too. So...yeah, Mistakes!

It's cool. Just wanted to make sure I wasn't loosing it.

I think this is an instance where "[doctest] uses a shallow copy of [a module] M‘s globals" Here's a failing doc-test demonstrating

SOME_CONSTANT = True

def test_constant_setting():
    """

    >>> SOME_CONSTANT = False
    >>> test_constant_setting()
    False

    """
    return SOME_CONSTANT
  • And execution in the repl
>>> SOME_CONSTANT
True
>>> test_constant_setting()
True
>>> SOME_CONSTANT = False
>>> SOME_CONSTANT
False
>>> test_constant_setting()
True

Wrapping the constant in a class allows it to be set in the test but then it's no longer a constant and will effect the running of other tests that reference it. Wrapping the whole in a Game class and setting it's dimensions in build_cell seems a decent start.

A test in this case might look something like

def get_moves(player):
    """Based on the tuple of the player's position, return the list of acceptable moves

    >>> cells = build_cells(2, 2)
    >>> get_moves((0, 0))
    ['RIGHT', 'DOWN']
    >>> get_moves((1, 1))
    ['LEFT', 'UP']

    """

Unfortunately that introduces classes which increases the complexity of the lesson.

Because the get_moves function uses the equality operator to check for specific board positions rather than an actual boundary, and there is no code that prevents using the get moves function in isolation with an illegal board position, the get_moves function returns an output that doesn't make sense given an illegal board position. Of course, provided the player starts on the board, which they always will when running the actual game, the get_moves function always works properly.