Game of Life in Sketchup; unittesting and TDD (pedagogy)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Game of Life in Sketchup; unittesting and TDD (pedagogy)

Kirby Urner-6

Hey Gregor, I'm being somewhat hopelessly abstruse (obtuse?) in this philosophy list.  

You'll see your name going by, in connection with that Wittgenstein sister's house in Vienna:


BBC spent some time on it (her house) in some erudite TV such as USAers tend to not make, only import.  

Fie on those dumbed down university Youtube stations, or maybe I'm missing the best links?

In other news, we've got Conway's Game of Life stacking up in Google SketchUp, per this earlier thread.



(feel free to join us on Facebook, note my invite to point to a favorite Game of Life implementation, using Python one would expect, if you're coming from edu-sig).

Nathan's was likely done in Ruby though, though he uses Python quite a lot.  I'll check with him and report back.

Wait... this just in:

"""
Well that was quick!

I considered using Python, but the API didn't look mature enough, and It turned out Ruby and Python have a lot in common.
-- 
Nathan H. Nifong
http://nathannifong.com
"""

I'm finding unittest as a centerpiece of a Python curriculum is quite an albatross in some respects, simply because the coding assignments are still small so the ratio of testing code to code being tested is rather too high.

That's neither an argument against test driven development (TDD), nor against unittest in a company context, where back office workbenches enforce company standards.

But when you're first donning the hat of "developer", you want that quick turnaround associated with running your module top level.  A little demo at the bottom gets the focus:

def _test( ):
   """ << demo of what this module might do for you >> """

if __name__ == "__main__":
    _test( )

is what we want to see in student projects, meaning what they release to the world comes with a kind of built in testing that shows off native functionality.

It's like doctest but different in that we're not showing interactions, though we could be.  

We're just giving the module a workout, making it do stupid pet tricks.  _test contains tests like the developer used to make the code pass, keeping some proof in the pudding.

_test( ) is what's portable, comes with the module as "batteries included".  

Behind the scenes, back at Mother Ship, you have your more ambitious testing framework.  So it's not either/or.

Kirby


_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Game of Life in Sketchup; unittesting and TDD (pedagogy)

Corey Richardson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/09/2011 07:11 PM, Kirby Urner wrote:
> It's like doctest but different in that we're not showing interactions,
> though we could be.

I saw in #python that someone was working on making doctest even more
useful, and having some of the features of unittest (and I believe he
was working on running doctests from unittests). I don't mind doctest in
smaller quantities, and sphinx makes it look good on the user-facing side.

When I'm teaching newcommers I used to avoid testing until the last
possible moment (even in my AP CS class we never once had to have formal
tests for our code...) to cover it, and it was scanty. Now I usually
teach mostly full TDD with the doctest module, and then show them
unittest later on. I think it makes the docstrings look ugly, but
testing is more important than aesthetics.

my 2c,
- --
Corey Richardson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNyI+wAAoJEAFAbo/KNFvpyXoIAIjwW0cJh9/llWj4ZsLmL9YE
IbnK9wHTurJFdMRt2l4FH1IlMRSBRzH+m5FBSVT/dfhgu4BA+BWDBx4Tif8ywt45
EIj1ratgD3qb7BPnBMA5f47ZAUlFMOKnFD8pUJibTYUM8uU5k7/7j9KSijj2Gwx4
LAjr9ESZV8cDrFh/wMZxWE5SuMqoKmQPBz7JLh+x54MJ2hdhwApcPOIgWSfMNxhX
/8yMmUcOUcgnFJh85dMGhJ3fZA1xtgHmy1N9hNF/f0lP3FIY+hcLyrP7WKwLOzw+
wI5HF8hK663Fk9M7SZQe4Wu4jZKvvGIYJt1ag4tuFDpfW2jcaYzOWYUALhriZQ0=
=4VOF
-----END PGP SIGNATURE-----
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Game of Life in Sketchup; unittesting and TDD (pedagogy)

Kirby Urner-6
On Mon, May 9, 2011 at 6:06 PM, Corey Richardson <[hidden email]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/09/2011 07:11 PM, Kirby Urner wrote:
> It's like doctest but different in that we're not showing interactions,
> though we could be.

I saw in #python that someone was working on making doctest even more
useful, and having some of the features of unittest (and I believe he
was working on running doctests from unittests). I don't mind doctest in
smaller quantities, and sphinx makes it look good on the user-facing side.

When I'm teaching newcommers I used to avoid testing until the last
possible moment (even in my AP CS class we never once had to have formal
tests for our code...) to cover it, and it was scanty. Now I usually
teach mostly full TDD with the doctest module, and then show them
unittest later on. I think it makes the docstrings look ugly, but
testing is more important than aesthetics.

my 2c,
- --
Corey Richardson

Seems a reasonable approach.  Likewise this OST curriculum sanely 
begins with core basics, phases in doctest, then unittest.  The TDD 
philosophy is well demonstrated and the author (SH) walks his talk.

However, I'm thinking to wedge something TDDish between doctest
and unittest that's just the engaged coder testing her own module in
top-level run mode (versus importing).  It's one of those delegating of
responsibility things that a module should have some standalone 
behaviors to model / demo what it brings to the table.  To that end,
a structure like:

def _test( ):
    """ testing code goes here, TDD is your friend """

if __name__ == "__main__":
   _test( ) 

is considered "good to go".  How does this support the "write tests
first" philosophy?

Well, imagine having this class:

class Farm:

    def __init__(self, rows=8, columns=8, bg="*"):
        self.h = rows
        self.w = columns
        self.bg = bg  # background character
        self.tractors = []  # like Snake or Dog stomach
        self.field = [list(bg*self.w) for x in range(self.h)]  # model
        self.framenumber = 0
        self.trace = []

    def render(self):
        display=""
        for line in self.field:
            display += "".join(line)+"\n"            
        return display  # view

    __str__ = render
    
    def __repr__(self):
        return "Farm({},{}) @ {}".format(self.w, self.h, id(self))

It basically builds an M x N array of stars, and now you want
to add the feature that you can peek or poke to that array
using a FORTRAN-like syntax i.e.

>>> myfarm = Farm(10,20)
>>> myfarm(3, 5) = "@"

will "plant" a "@" in row 3 column 5 of the data structure,
named self.field.  The coder would simply embed this expected
feature in _test:

def _test():
    myfarm = Farm(10,20)

    # before picture
    print(myfarm)

    myfarm(3, 5) = "@"

    # after picture
    print(myfarm)  

It's clear to the coder what's expected, so there's the test.  Now
the goal is to add the minimum code to Farm that makes this work.

Example (continued):


class Farm:

    # << code already shown >>

    def __getitem__(self, key):   # from arr4.py
        "Returns the appropriate element for a two-element subscript tuple."
        r, c = key      
        return self.field[r][c]   # from arr4.py
    
    def __setitem__(self, key, value):
        "Sets the appropriate element for a two-element subscript tuple."
        r, c = key
        self.field[r][c] = value

Run the module top-level, triggering _test, and do so again and again, 
as contingencies and corner cases get tested.  Leave a representative
set of tests behind as evidence of your audit.  You may write a more
formal unittesting framework later, but there's no guarantee that's 
something to release with the module.  The _test( ) function serves 
as an "on board payload" while the unittest framework stays behind
"near the launch pad".

The goal is to put the learner in the role of Quality Assurance tester,
at least at first.  Eat your own dog food.  Keep the code to be tested 
and the tester code together, but that doesn't have to mean doctest.

Kirby


_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Game of Life in Sketchup; unittesting and TDD (pedagogy)

Corey Richardson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/09/2011 09:46 PM, Kirby Urner wrote:

> Run the module top-level, triggering _test, and do so again and again,
> as contingencies and corner cases get tested.  Leave a representative
> set of tests behind as evidence of your audit.  You may write a more
> formal unittesting framework later, but there's no guarantee that's
> something to release with the module.  The _test( ) function serves
> as an "on board payload" while the unittest framework stays behind
> "near the launch pad".
>
> The goal is to put the learner in the role of Quality Assurance tester,
> at least at first.  Eat your own dog food.  Keep the code to be tested
> and the tester code together, but that doesn't have to mean doctest.

I really like that approach, I think I'll start using it myself! Thanks
for imparting your wisdom.

And about the Game of Life:
I'm starting to pick up a little VBA (eugh it's gross) and plan on
implementing (if I can, of course) the Game of Life in an excel
spreadsheet! Now that I think about it, I wonder if libreoffice has
scripting and what it is...
- --
Corey Richardson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNyJ5wAAoJEAFAbo/KNFvpZYsH/16gHa2rM2hrp47P+g++arQ0
wRf1hSdbCfIZwoKXHKxL2cPgtMqwACZrYt2+eBgnu0aRNZBujXIS76ITd6qekSic
Hrj3kx6ZpiE5RRnb1OyXbcMWVCF6nI540t348nCdutr6edytBSlQ45vyKpqS+los
Q3QRwvQi0cj+go1xodutktR5pvA16shCpx8CdGcIX8RRTRjTvVi/CkhMO3zHK9qT
06wRuYa3bveR86xnOHyhHgtj4wBtf8ip9bnhZTXEQlAdPOhyvAh8KmEpwlpqq/fj
tOAexh1hpwohXBOTZaSjiTF+/JwglP77XgQ8rcmHFkIomwKxG3LO6YHnHcDIxGc=
=LhOj
-----END PGP SIGNATURE-----
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig