> Steve Howell wrote: > > --- Steven Bethard <steven.beth...@gmail.com> > wrote: > >> I think I would rewrite the current unit-testing > >> example to use the > >> standard library unittest module::
> >> # Let's write reusable code, and unit test > it. > >> def add_money(amounts): > >> # do arithmetic in pennies so as not to > >> accumulate float errors > >> pennies = sum([round(int(amount * 100)) > for > >> amount in amounts]) > >> return float(pennies / 100.0) > >> import unittest > >> class TestAddMoney(unittest.TestCase): > >> def test_float_errors(self):
> > Just a minor quibble, but wouldn't you want the > import > > and test class to only get executed in the > ___main__ > > context?
> That would be fine too. In the real world, I'd put > the tests in a > different module.
Maybe this is the first good example that motivates a hyperlink to alternatives. Would you accept the idea that we keep my original example on the SimplePrograms page, but we link to a UnitTestingPhilosophies page, and we show your alternative there? Or vice versa, show your example on the first page, but then show mine on the hyperlinked page?
I am in 100% agreement with you that most unit tests would be completely outside the module, although I often follow the practice that my modules have a little "if __main__" section that runs a few simple unit tests, as sort of a bit of self-documentation.
___________________________________________________________________________ _________Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting
Steve Howell wrote: > --- Steven Bethard <steven.beth...@gmail.com> wrote:
>> Steve Howell wrote: >>> --- Steven Bethard <steven.beth...@gmail.com> >> wrote: >>>> I think I would rewrite the current unit-testing >>>> example to use the >>>> standard library unittest module::
>>>> # Let's write reusable code, and unit test >> it. >>>> def add_money(amounts): >>>> # do arithmetic in pennies so as not to >>>> accumulate float errors >>>> pennies = sum([round(int(amount * 100)) >> for >>>> amount in amounts]) >>>> return float(pennies / 100.0) >>>> import unittest >>>> class TestAddMoney(unittest.TestCase): >>>> def test_float_errors(self):
>>> Just a minor quibble, but wouldn't you want the >> import >>> and test class to only get executed in the >> ___main__ >>> context? >> That would be fine too. In the real world, I'd put >> the tests in a >> different module.
> Maybe this is the first good example that motivates a > hyperlink to alternatives. Would you accept the idea > that we keep my original example on the SimplePrograms > page, but we link to a UnitTestingPhilosophies page, > and we show your alternative there? Or vice versa, > show your example on the first page, but then show > mine on the hyperlinked page?
> I've heard good things about it, but haven't gotten > around to trying it > yet. Here's a two-line test suite from the page > above:
> def test_answer(): > assert 42 == 43
Changed the subject line.
Nope, I haven't. I'm a tremendous advocate of unit testing, but I've never felt compelled to try out other libraries, because I work mostly on private code now, so the following-standard-practices-to-benefit-from-familiarity argument doesn't carry much weight with me, and also because I find it easy enough to do things on a roll-your-own basis. YMMV, of course.
I have slowly introduced unit testing into my own work environment, with some success. We don't use a 3rd party testing framework, but here's my roll-your-own approach:
1) For flat-out failures, we just fail with a traceback right away. We don't bother to capture stats on how many tests failed. If one test fails, that's enough to clue in a developer that he/she broke something.
2) We don't use assertions very often, but rather just diff the output files to the GOLD files. This may eventually stop to scale, but it hasn't yet.
3)We have a little trickery to override imports, etc., as 99.99% of our code was never written with unit testing in mind, but I still want to regression test it.
4) We have quite a few mock-ish objects, mainly relating to simulating I/O situations.
___________________________________________________________________________ _________Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/
> > Maybe this is the first good example that > motivates a > > hyperlink to alternatives. Would you accept the > idea > > that we keep my original example on the > SimplePrograms > > page, but we link to a UnitTestingPhilosophies > page, > > and we show your alternative there? Or vice > versa, > > show your example on the first page, but then show > > mine on the hyperlinked page?
> Sure. Either way is fine.
Ok, for now, I'm taking no action, let's let the unit testing discussion progress a little. Despite my saying early that I don't want to debate it, I do want to discuss it :), as it is near in dear to my heart.
Steven Bethard <steven.beth...@gmail.com> writes: > I think I would rewrite the current unit-testing example to use the > standard library unittest module::
I think these days we're supposed to like doctest better than unittest.
>> I've heard good things about it, but haven't gotten >> around to trying it >> yet. Here's a two-line test suite from the page >> above:
>> def test_answer(): >> assert 42 == 43
> Changed the subject line.
> Nope, I haven't. I'm a tremendous advocate of unit > testing, but I've never felt compelled to try out > other libraries, because I work mostly on private code > now, so the > following-standard-practices-to-benefit-from-familiarity > argument doesn't carry much weight with me, and also > because I find it easy enough to do things on a > roll-your-own basis. YMMV, of course.
My view is generally that if I can get someone else to maintain parts of my code for me, that's a good thing. ;-)
> 1) For flat-out failures, we just fail with a > traceback right away.
Looks like that's the -x/--exitfirst option in py.test.
> 2) We don't use assertions very often, but rather > just diff the output files to the GOLD files. This > may eventually stop to scale, but it hasn't yet.
I guess I don't do enough stuff with file input and file output for this to make sense for me.
> 3)We have a little trickery to override imports, > etc., as 99.99% of our code was never written with > unit testing in mind, but I still want to regression > test it.
> 4) We have quite a few mock-ish objects, mainly > relating to simulating I/O situations.
Let me preface every reply here by YMMV. I strongly, strongly encourage people to tap into the unit testing community for all tools that are available to them.
Also, let me say that despite any place where Steven and I disagree about the mechanics of unit testing, we're in firm agreement that UNIT TESTING IS IMPORTANT. And sorry for shouting. And, really, if you're not doing automated tests on your application now, you don't know what you're missing.
--- Steven Bethard <steven.beth...@gmail.com> wrote:
> > 1) For flat-out failures, we just fail with a > > traceback right away.
> Looks like that's the -x/--exitfirst option in > py.test.
Yes, but for my purposes, it's even easier to do absolutely nothing when a test fails, just let it pass through.
> > 2) We don't use assertions very often, but > rather > > just diff the output files to the GOLD files. > This > > may eventually stop to scale, but it hasn't yet.
> I guess I don't do enough stuff with file input and > file output for this > to make sense for me.
First, I should say that we don't completely ignore assertion tests, as it's useful for testing truly functional code, such as something that simply parses a message.
But most of our application is I/O driven, and the actual tricky modules of our application do manage a conversation between a terminal and a host, and it's that conversation between the terminal that we want to proceed in a predictable fashion.
> > 4) We have quite a few mock-ish objects, mainly > > relating to simulating I/O situations.
Again, this is a case, where pardon my arrogance, I already know how my objects work, so I already know how to emulate them. I've read up on mock objects, so I'm not totally ignoring common wisdom, it's just that I get it, have a powerful language at my disposal, etc. I fully concede that my mock objects might be missing key features from the Python Mock module, but I also assert that I can implement pretty robust unit testing without it.
Steve Howell wrote: > I've always thought that the best way to introduce new > programmers to Python is to show them small code > examples.
This is really a nice piece of missing Python.
Sorry I didn't follow this thread accurately, but have you considered to produce an example environment like in wxPython ?
The wxPython demo program is written as an interactive tutorial, with a few hundred examples, nicely ordered in groups. The user can view the demo, the code and the help text. The user can also change the code and see the results right away.
It would even be nicer, if everybody could drop her/his examples in a standard way, so they would be automatically incorporated in something like the wxPython interactive demo.
> Steve Howell wrote: > > I've always thought that the best way to introduce > new > > programmers to Python is to show them small code > > examples.
> This is really a nice piece of missing Python.
Thanks.
> The wxPython demo program is written as an > interactive tutorial, > with a few hundred examples, nicely ordered in > groups. > The user can view the demo, the code and the help > text. > The user can also change the code and see the > results right away.
Do you have a link?
> It would even be nicer, if everybody could drop > her/his examples > in a standard way, so they would be automatically > incorporated in > something like the wxPython interactive demo.
Can you elaborate?
___________________________________________________________________________ _________ 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news
>> The wxPython demo program is written as an >> interactive tutorial, >> with a few hundred examples, nicely ordered in >> groups. >> The user can view the demo, the code and the help >> text. >> The user can also change the code and see the >> results right away.
>> It would even be nicer, if everybody could drop >> her/his examples >> in a standard way, so they would be automatically >> incorporated in >> something like the wxPython interactive demo.
> Can you elaborate?
Well if you see the above demo, I've the following in mind: - create a new-demo in a special directory - add some special keywords in the new-demo, in which treenodes it should popup - on restart of the demo, the new-demo is added to the tree
> >> It would even be nicer, if everybody could drop > >> her/his examples > >> in a standard way, so they would be automatically > >> incorporated in > >> something like the wxPython interactive demo.
> > Can you elaborate?
> Well if you see the above demo, > I've the following in mind: > - create a new-demo in a special directory > - add some special keywords in the new-demo, in > which treenodes it should popup > - on restart of the demo, the new-demo is added to > the tree
To the extent that you just want a group of people to be able to organically organize a tree-like collection of Python examples, you could use a MoinMoin that has sensible page names and the Local Site Map featured turn on. Are you also suggesting the need for something local, so that you can actually run the programs?
Steve Howell wrote: > --- Stef Mientki <S.Mientki-nos...@mailbox.kun.nl> > wrote: >>>> It would even be nicer, if everybody could drop >>>> her/his examples >>>> in a standard way, so they would be automatically >>>> incorporated in >>>> something like the wxPython interactive demo.
>>> Can you elaborate? >> Well if you see the above demo, >> I've the following in mind: >> - create a new-demo in a special directory >> - add some special keywords in the new-demo, in >> which treenodes it should popup >> - on restart of the demo, the new-demo is added to >> the tree
> To the extent that you just want a group of people to > be able to organically organize a tree-like collection > of Python examples, you could use a MoinMoin that has > sensible page names and the Local Site Map featured > turn on. Are you also suggesting the need for > something local, so that you can actually run the > programs?
I don't know MoinMoin, but the answer is Yes (although maybe not for your ten snippets). First of all I think all programmers keep there own collection of code snippets, which much more valuable then "all the code code snippets from everyone". Secondly, Python is nowadays not only used by programmers, but also by e.g. Scientific users (former MatLab users), who are not interested in the code itself, but just in the results of that particular code. For these people a lot of example programs, for which they can easily see the results, make some small changes and see the result again, would be a wonderful addition.
> I don't know MoinMoin, > but the answer is Yes (although maybe not for your > ten snippets). > First of all I think all programmers keep there own > collection of code snippets, > which much more valuable then "all the code code > snippets from everyone".
Agreed.
> Secondly, Python is nowadays not only used by > programmers, > but also by e.g. Scientific users (former MatLab > users), > who are not interested in the code itself, > but just in the results of that particular code. > For these people a lot of example programs, > for which they can easily see the results, > make some small changes and see the result again, > would be a wonderful addition.
In your own personal use, what are some libraries/techniques/etc. that you think could benefit from some kind of more organized presentation of example programs (or better way of showing how the examples work, etc.)? Are you part of the Scientific community?
How new are you to Python? I do think newbies/intermediates/advanceds all have different needs.
___________________________________________________________________________ _________Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting
>> Secondly, Python is nowadays not only used by >> programmers, >> but also by e.g. Scientific users (former MatLab >> users), >> who are not interested in the code itself, >> but just in the results of that particular code. >> For these people a lot of example programs, >> for which they can easily see the results, >> make some small changes and see the result again, >> would be a wonderful addition.
> In your own personal use, what are some > libraries/techniques/etc. that you think could benefit > from some kind of more organized presentation of > example programs (or better way of showing how the > examples work, etc.)?
for example SciPy, but I think it yield for all libs/techniques. And I guess Windows users have a much greater need for such an organization than *nix users.
> Are you part of the Scientific > community?
sort of, I indeed work at a university, but not doing scientific work myself, I work on a supporting department.
> How new are you to Python?
very new ;-) (I've lot of experience in a other programming languages, last years mostly Delphi, JAL, MatLab)
> I do think > newbies/intermediates/advanceds all have different > needs.
|
