UnitTest?

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

UnitTest?

Zac Miller
Does anyone teach any unittest or test driven development to high school (or other) students?  I'm looking for a quick reference or "cheat sheet" for python's unittest that I found around the internet once and never bookmarked.  I may be imagining it but I remember it being great.  If anyone knows the one that I think I saw one time or has a great one they wouldn't mind sharing I'd be very thankful!  If not...perhaps it is my destiny to create one.

-J. Zachary Miller


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

Re: UnitTest?

Corey Richardson
On 02/23/2011 11:05 PM, Zac Miller wrote:
> Does anyone teach any unittest or test driven development to high school (or other) students?  I'm looking for a quick reference or "cheat sheet" for python's unittest that I found around the internet once and never bookmarked.  I may be imagining it but I remember it being great.  If anyone knows the one that I think I saw one time or has a great one they wouldn't mind sharing I'd be very thankful!  If not...perhaps it is my destiny to create one.
>

I found
https://portal.g-node.org/python-summerschool-2009/_media/cheat_sheets.pdf

As a student, I wish we covered testing in class. It's a very useful skill!


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

Re: UnitTest?

kirby urner-4
In reply to this post by Zac Miller

I'm teaching it as a part of O'Reilly School of Technology's certificate program in Python 3.  Steve Holden is the curriculum author.

Thanks for asking this question.  Corey's link looks useful, although Chrome is anxious about it having security problems.
 
Kirby


On Wed, Feb 23, 2011 at 8:05 PM, Zac Miller <[hidden email]> wrote:
Does anyone teach any unittest or test driven development to high school (or other) students?  I'm looking for a quick reference or "cheat sheet" for python's unittest that I found around the internet once and never bookmarked.  I may be imagining it but I remember it being great.  If anyone knows the one that I think I saw one time or has a great one they wouldn't mind sharing I'd be very thankful!  If not...perhaps it is my destiny to create one.

-J. Zachary Miller


_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig


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

Re: UnitTest?

Vernon D. Cole
In reply to this post by Zac Miller
I think for most high-school level work, use of the "assert" statement would be the first thing to teach.
It can be used in an "if __name__ == '__main__': " construct in a module to make a good quick test.

see https://launchpad.net/romanclass as an example.

Simple modules do not need anything as complex as unittest. It would be a good advanced subject, though.
--
Vernon Cole


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

Re: UnitTest?

Vern Ceder-3
On Thu, Feb 24, 2011 at 11:25 AM, Vernon Cole <[hidden email]> wrote:
> I think for most high-school level work, use of the "assert" statement would
> be the first thing to teach.

Doctests can also be good way to introduce the idea of testing. It's
maybe a bit easier for beginners to grasp and a very natural Python
technique.

Vern

> It can be used in an "if __name__ == '__main__': " construct in a module to
> make a good quick test.
>
> see https://launchpad.net/romanclass as an example.
>
> Simple modules do not need anything as complex as unittest. It would be a
> good advanced subject, though.
> --
> Vernon Cole
>
>
> _______________________________________________
> Edu-sig mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/edu-sig
>
>



--
Vern Ceder
[hidden email], [hidden email]
The Quick Python Book, 2nd Ed - http://bit.ly/bRsWDW
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: UnitTest?

kirby urner-4

Yeah these are both good suggestions.

It's fun to throw maybe one or two examples of unittest into the mix, maybe already written (so-called scaffolding).

But unless it's a course about programming / development and nothing more, flogging unittest (aka PyUnit) might seem too much of a detour.

In the OST course, there's some doctest towards the end of Python 1, with unittest the main opening topic of Python 2 (which also includes using MySQL as a back end and the Tk GUI was a front end).

In a more purely math-oriented course, I still think of Sqlite as a great place to stash polyhedrons in relational tables.  VPython is still my favorite library for geometry topics, though I'm still a big fan of POV-Ray after all these years.



Kirby

On Thu, Feb 24, 2011 at 8:31 AM, Vern Ceder <[hidden email]> wrote:
On Thu, Feb 24, 2011 at 11:25 AM, Vernon Cole <[hidden email]> wrote:
> I think for most high-school level work, use of the "assert" statement would
> be the first thing to teach.

Doctests can also be good way to introduce the idea of testing. It's
maybe a bit easier for beginners to grasp and a very natural Python
technique.

Vern

> It can be used in an "if __name__ == '__main__': " construct in a module to
> make a good quick test.
>
> see https://launchpad.net/romanclass as an example.
>
> Simple modules do not need anything as complex as unittest. It would be a
> good advanced subject, though.
> --
> Vernon Cole
>
>
> _______________________________________________
> Edu-sig mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/edu-sig
>
>



--
Vern Ceder
[hidden email], [hidden email]
The Quick Python Book, 2nd Ed - http://bit.ly/bRsWDW
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig


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

Re: UnitTest?

Laura Creighton-2
The children I have taught have had absolutely no problem with py.test.
They wouldn't have had problems with nose, either.  unittest is a bit
wordy for them.  And as far as I am concerned, unless you happen to
need to test the formatting of your documentation, you shouldn't be
using doctest at all.

Laura

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

Re: UnitTest?

David MacQuigg
In reply to this post by Zac Miller
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.

The main limitation of doctest is that it doesn't preserve values or
maintain a set order when testing a bunch of functions.  That can be
fixed, however, by providing your own framework - a test function that
calls the other functions in whatever order you want.  The framework
test is then just another doctest in the test function itself.  This is
a simple extension of what the students already know.

--
************************************************************     *
* 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          *
************************************************************     *



On 2/23/11 9:05 PM, Zac Miller wrote:
> Does anyone teach any unittest or test driven development to high school (or other) students?  I'm looking for a quick reference or "cheat sheet" for python's unittest that I found around the internet once and never bookmarked.  I may be imagining it but I remember it being great.  If anyone knows the one that I think I saw one time or has a great one they wouldn't mind sharing I'd be very thankful!  If not...perhaps it is my destiny to create one.
>
> -J. Zachary Miller

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

Re: UnitTest?

Laura Creighton-2
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

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

Re: UnitTest?

David MacQuigg
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-underappreciated/
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
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: UnitTest?

kirby urner-4
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
<[hidden email]> 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-underappreciated/
> 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
> [hidden email]
> http://mail.python.org/mailman/listinfo/edu-sig
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig