Notes for Session 08

May 28, 2019

NOTE: These notes are “live” – they will change up until the class starts.

A collection of notes to go over in class, to keep things organized.

Lightning Talks (last)

Peter Berhe

Jasneet Chandok

Issues that came up during the week.

What to test? And how?

Make sure you test what matters about a function’s result – it’s easiest (particularly if you wrote the code first) to simply match results, but your system will be more flexible if you test for the parts that matter, and won’t change.

Ideally, your tests should be as isolated as possible. So if you, for instance, need to test that the correct letter is generated from a donor object, then create a donor object in the test, and pass that in, rather than pulling it from the donor_db – that way, the donor_db could be broken, and the individual tests will pass.

If the object(s) you need to create are complex, then you can use “fixtures” to set things up for you. We’ll get into that in the next quarter.

This will start to make more and more sense as we do more testing – and particularly when we do TDD and write the tests along with the code.

Example:
def test_p_tag():
    assert Para.tag == 'p'

I know I started out that way – ‘cause there wasn’t anything else to test. But this is really testing an implementation detail – the Para elements has a attribute named “tag” that is ‘p’. But is that a public part of the API? do we care? – No. What we care about is that the correct tag gets rendered, so a test for THAT makes more sense:

def test_render_para():
    my_stuff = 'spam, spam, spam'
    p = Para(my_stuff)
    more_stuff = 'eggs, eggs, eggs'
    p.append(more_stuff)
    contents = render_element(p).strip()
    assert contents.startswith('<p>')
    assert contents.endswith('</p>')
    assert my_stuff in contents
    assert more_stuff in contents

Do you always need an __init__?

No – you don’t :-)

The ONLY thing “special” about __init__ is that it is automatically called when an instance is created. Other than that, it’s a regular method. So if you don’t define one, then the superclass’ __init__ will be called.

That’s what inheritance is all about – the subclass inherits ALL the superclasses methods – including __init__.

So never write an __init__ that does nothing but call the superclass __init__

Subclasses and self

self is the first parameter in all methods. But why??

self is the “current” instance of the object. This means that you don’t know at code writing time what type it is – is it the current class? some subclass?

Let’s experiment with that.

html_render

I’m not sure many of you got the whole thing done – that’s OK – it’s a LOT.

If you are really tangled up, you can look at my solution:

SP_2019_210A_classroom/solutions/Lesson07

Or better yet – Anyone want a code review?

Lightning Talks