In a message of Sat, 26 Feb 2011 10:28:58 MST, David MacQuigg writes:
In my opinion, the unittest framework is way too cumbersome for an introductory course. Doctests are simple and self-explanatory. Students should get in the habit of writing a doctest for every function they write, even before the function itself is written.
I think this is a reason to use py.test or nose rather than unittest, but not a reason to use doctest. I'm very fond of Mark Pilgrim's Unit testing chapter in Dive into Python http://diveintopython.org/unit_testing/index.html (2.x) http://diveintopython3.org/unit-testing.html (3.x) which is easy to adapt to a less verbose testing framework. Laura
As usual, Pilgrim does an excellent job of explaining his topic. I haven't looked at unittest for years, but Chapter 9 in his new book explains it well. That said, I still prefer doctest over unittest. 1) doctests can be introduced on day one, without much explanation. Pilgrim waits until Chapter 9 to introduce the unittest module, and then the presentation depends on students already knowing how to define classes. At that point, it is much harder to get students to change their habits, and start writing tests for even the simplest functions. Even worse, students who stop short of learning OOP, and that includes most who are not intending to be programmers, those students will never appreciate the value of including tests as an integral part of writing a program. 2) doctests look just like what students will enter in an interactive session, while testing some function they have just written. Cut-and-paste a successful test from the interpreter to the editor window, and you are done. 3) doctests serve two functions - documentation and testing. Start with a simple well-written doctest to make the purpose of a function crystal clear. Then add numerous unit tests, one at a time as you think of them, placing them in a separate test function to a avoid a conflict between clarity and completeness. Refine your doctests to make the explanation even more clear, but don't throw away your old doctests. Just move them to the unit test function. 4) The explanatory doctests are what motivate students to write any tests at all. Without this, writing tests gets put off to the end, or never done. Google [python doctest] for lots of interesting discussion. Two very helpful links: http://blog.tplus1.com/index.php/2008/07/14/python-doctests-seem-underapprec... http://stackoverflow.com/questions/361675/python-doctest-vs-unittest See pykata.org for examples that make extensive use of doctests for both explanation and unit testing. On 2/26/11 11:25 AM, Laura Creighton wrote:
In a message of Sat, 26 Feb 2011 10:28:58 MST, David MacQuigg writes:
In my opinion, the unittest framework is way too cumbersome for an introductory course. Doctests are simple and self-explanatory. Students should get in the habit of writing a doctest for every function they write, even before the function itself is written. I think this is a reason to use py.test or nose rather than unittest, but not a reason to use doctest. I'm very fond of Mark Pilgrim's Unit testing chapter in Dive into Python http://diveintopython.org/unit_testing/index.html (2.x) http://diveintopython3.org/unit-testing.html (3.x)
which is easy to adapt to a less verbose testing framework.
Laura
-- ************************************************************ * * David MacQuigg, PhD email: macquigg at ece.arizona.edu * * * Research Associate phone: USA 520-721-4583 * * * * ECE Department, University of Arizona * * * * 9320 East Mikelyn Lane * * * *http://purl.net/macquigg Tucson, Arizona 85710 * ************************************************************ *
Per the Steve Holden curriculum, which I'm currently teaching, we start with doctest and get students familiar with the whole idea of test driven development (TDD), which is presented as an aspect of "agile programming". The beginner level leaves it at that, with the intermediate course starting in on unittest.[0] The downside of doctest is it clutters docstrings, meant to provide help to a user, with lots of testing noise. One could argue this is "documentation by example" but it doesn't fit the template of standard library or 3rd party docstrings. Also, unittest lets you set up dummy files and directories, other stub resources (so-called fixtures) before moving on to the actual test. And you can separated the test suites from the actual module being tested, reserving the former for the dev platform, the latter for distribution. The thing about CS is it's highly vocational so you wouldn't just Show & Tell about this stuff, to develop a reading knowledge (like of Latin [1]) and then move on to other topics, e.g. tcp/ip. That'd be more like an "engineering for poets" class. Those doing a lot of hands-on unittest in Standard University are implicitly committing to x hours per week doing programming, whereas those studying through OERs etc. might just wanna dabble to get a sense of it. Like going to a user group talk, not on the hook to turn in assignments on unittest in particular.[3] The Holden course is of the standard variety, meaning it's all about hands-on and assumes a pretty high level of commitment, in terms of wanting to learn the ins and outs and have them stick. It's not just "exposure" like the poets might get. Kirby [0] http://www.oreillyschool.com/courses/python1/ (Steve being interviewed by Trish during the recently concluded annual staff meeting) [1] I've been telling students that Ruby, Python and Perl are like Spanish, French and Italian (though I don't say what maps to what) in terms of being of the same family (Latin aka Romance languages). As Rob remarked (a Ruby guy), that's an analogy Larry Wall should appreciate. [2] OERs = open courseware, like you can get from MIT, Yale etc. On Sun, Feb 27, 2011 at 5:37 PM, David MacQuigg <macquigg@ece.arizona.edu> wrote:
As usual, Pilgrim does an excellent job of explaining his topic. I haven't looked at unittest for years, but Chapter 9 in his new book explains it well.
That said, I still prefer doctest over unittest. 1) doctests can be introduced on day one, without much explanation. Pilgrim waits until Chapter 9 to introduce the unittest module, and then the presentation depends on students already knowing how to define classes. At that point, it is much harder to get students to change their habits, and start writing tests for even the simplest functions. Even worse, students who stop short of learning OOP, and that includes most who are not intending to be programmers, those students will never appreciate the value of including tests as an integral part of writing a program. 2) doctests look just like what students will enter in an interactive session, while testing some function they have just written. Cut-and-paste a successful test from the interpreter to the editor window, and you are done. 3) doctests serve two functions - documentation and testing. Start with a simple well-written doctest to make the purpose of a function crystal clear. Then add numerous unit tests, one at a time as you think of them, placing them in a separate test function to a avoid a conflict between clarity and completeness. Refine your doctests to make the explanation even more clear, but don't throw away your old doctests. Just move them to the unit test function. 4) The explanatory doctests are what motivate students to write any tests at all. Without this, writing tests gets put off to the end, or never done.
Google [python doctest] for lots of interesting discussion. Two very helpful links: http://blog.tplus1.com/index.php/2008/07/14/python-doctests-seem-underapprec... http://stackoverflow.com/questions/361675/python-doctest-vs-unittest
See pykata.org for examples that make extensive use of doctests for both explanation and unit testing.
On 2/26/11 11:25 AM, Laura Creighton wrote:
In a message of Sat, 26 Feb 2011 10:28:58 MST, David MacQuigg writes:
In my opinion, the unittest framework is way too cumbersome for an introductory course. Doctests are simple and self-explanatory. Students should get in the habit of writing a doctest for every function they write, even before the function itself is written.
I think this is a reason to use py.test or nose rather than unittest, but not a reason to use doctest. I'm very fond of Mark Pilgrim's Unit testing chapter in Dive into Python http://diveintopython.org/unit_testing/index.html (2.x) http://diveintopython3.org/unit-testing.html (3.x)
which is easy to adapt to a less verbose testing framework.
Laura
-- ************************************************************ * * David MacQuigg, PhD email: macquigg at ece.arizona.edu * * * Research Associate phone: USA 520-721-4583 * * * * ECE Department, University of Arizona * * * * 9320 East Mikelyn Lane * * * *http://purl.net/macquigg Tucson, Arizona 85710 * ************************************************************ *
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
participants (3)
-
David MacQuigg -
kirby urner -
Laura Creighton