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.
-- 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 |
-----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 |
On Mon, May 9, 2011 at 6:06 PM, Corey Richardson <[hidden email]> wrote:
-----BEGIN PGP SIGNED MESSAGE----- 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 |
-----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 |
Free forum by Nabble | Edit this page |