[V2] zipper: several small issues in the tests

I have several things I think are not correct on this exercise.

First, a small detail, I think there is a bug in the example set_value method (it mutates the object). I don’t know if there are other (similar) bugs, I’ll test that latter.

Secondly, and most importantly, one of the tests forces the student to do something odd. This is a bit long to explain and I’m not sure I can be really clear on the subject, but here it is:

I think this test (generated from this) is conceptually incorrect:

def test_dead_end(self):
        t1, _, _, _ = self.create_trees()
        zipper = Zipper.from_tree(t1)
        self.assertIsNone(zipper.left().left())

The tree t1 is the following:

     1
    / \
   2   4
    \
     3

While there is indeed no node at location .left().left(), this is still a valid location for a cursor to be at. From this position we could insert a node. And that’s sounds like the best way to insert a leaf in a tree as otherwise (if this was returning None as expected in the test) you would have to have two distincts leaf insertion methods insert_left and insert_right. I find it more satisfying to have the following working:

z = Zipper()
z = z.insert(1).right().insert(4).up().left().insert(2).left().insert(3)

This requires having the ability to navigate to non-yet-existing leafs (What?). In that case, the zipper simply contains None as the current tree but still has a context attached to it (and therefore, the zipper is not None, it has a context).

I know that the current tests do not include an insert method, but changing this test would allow to add (leaf) insertions in the goals of the exercise (especially because it would help having a clearer test set).

Why? By adding an insert method, we allow tests to rely only on the capabilities of the Zipper class only, which mean we could totally get rid of the from_tree/to_tree logic (together with the set_left/set_right in the current form). I think It would be nice because the tests would look more natural, which would help students understand zippers. Having to read an input graph (nested dictionaries), to then turn it to a zipper, and finally give it back in the form of a graph (same for as the input) doesn’t really help understanding the zipper purpose as this may look totally un-efficient (and it is).

What could be interesting to have as first tests is the immutability of the zipper objects, for example (note that I would like to have all tests using this construction for trees instead of the current zipper_test.py:bt method):

def test_immutability_move_insert(self):
    z = Zipper().insert(1).right().insert(4).up().left().insert(2).left().insert(3).left()
    z_2 = z.insert(5)
    z_3 = z.insert(7)
    self.assertIs((z.focus is None), True)
    self.assertEqual(z.up().value(), 3)
    self.assertNotEqual(z_2.value(), z_3.value())

def test_immutability_set_value(self):
    z = Zipper().insert(1).right().insert(4).up().left().insert(2).left().insert(3)
    z_2 = z.set_value(5)
    self.assertEqual(z.value(), 3)
    self.assertEqual(z_2.value(), 5)

Anyway, let me know what you think about this, if you think I’m not drunk and/or crazy I can suggest a new version of the tests.

[cmccandless]

Generally, starting with the abstract is easier. If working exclusively in the abstract becomes confusing (happens with complex tests), I suggest working in a familiar language (since you’re here, I’d suggest Python) in parallel with the abstract.

[BethanyG]

Since we’ve both gone through making a test generation template for this exercise and several updates from problem-specifications, I think this issue has largely been addressed. If not, please open a fresh issue against the current form of the exercise. Many thanks for the thoughtful discussion.