Slashdot Mirror
Testing Frameworks in Python
An anonymous reader writes "This article looks at Python's two standard modules for unit testing: unittest and doctest. These modules expand on the capability of the built-in assert statement, which is used for validation of pre-conditions and post-conditions within functions. The author discusses the best ways to incorporate testing into Python development, weighing the advantages of different styles for different types of projects."
Judging from some previous comments, I see that some fail to grasp that modern computer languages form a large ecosystem. Each language has its purpose, and one can not easily dismiss a language as dead, just because some other, ostensibly more powerful language has appeared on the block. Monkeys, whales, cockroaches, ants, and plants continue to coexist with humans.
.
When I want to solve a program I choose the language I will use, taking into account the abstractions and facilities it offers. * I chose Java when I wanted to leverage the javadoc applets (doclets) to convert a Java-like syntax into UML with my UMLgraph tool
* I chose C++ to implement the CScout refactoring browser for C programs. In this case I wanted rich and efficient data structures, with minimal speed and space overhead. CScout datasets can require more than 1GB of RAM, and runtimes can span more than a day; any overhead of object boxing, garbage collection, or bytecode interpretation would in this case be unacceptable.
* I chose Perl to o Convert digital photographs and GPS track logs into annotated photo albums and trip maps
o Examine the availability of 4500 URLs cited in computer science research papers.
o To create the diagrams and the index for my book Code Reading: The Open Source Perspective.
In all the above cases, I needed a typeless language with a rich set of operators, functions, and libraries to minimize the time I would spend to convert my ideas into code. Ruby and Python would have served me equally well.
* Finally, I chose C to write
o the *BSD sed implementation.
o The socketpipe zero-overhead network pipe tool.
o The Outwit Windows-Unix shell integration tool suite.
o The fileprune backup file prune utility.
o A device driver for interfacing with my home's alarm system.
In these cases, I did not require any fancy data structures or framework APIs, but I did want tight integration with the underlying system, absolute efficiency, and minimum-fuss portability. For code that will be executed billions of times on tens of thousands of systems, spending some additional effort to provide the absolute efficiency and reasonable portability that are possible in C, is a proposition one should take into account.
True programmers never test their code, that is for people who are unsure of themselves and who should not be trusted
Despite that fact that you are clearly trolling I think there's a valid point in what you are saying: there are programmers who think that they are too good to write unit or system tests for their code. And that's a real danger.
The adage "a line of untested code is a line of broken code" is so often true that I still find it scary when examining untested code. It's just amazing how much of a difference the discipline of writing automatic unit tests makes in improving code.
If you think you are too good to write tests, then perhaps you are too good for the software industry?
John.
You're not a "long time Python developer." Far from it. You may qualify as a "python developer from a long time ago," though -- in fact, that seems likely, given that the page you linked was last modified in 1999.
:)
It's Guido van Rossum, not Guido van Sustren. And Python's garbage collector works fine on cycles, as it has done since 2.0, iirc. The only way you'll get a memory leak with Python these days is by writing a C module that forgets some DECREFs or by writing cyclic objects with __del__ methods, and even in the latter case, you can easily take care of your leaks by breaking the cycle yourself.
You're uninformed and incorrect; take your troll to the next Perl story, please
Jeremy
Looking for a Python IRC bot?
What you're saying puzzles me. You're absolutely right that this article is not about testing as a whole. The title should have been "Unit Testing Frameworks in Python."
But your statement that "this is about hacking" and not professional software development puzzles me.
I believe unit tests are a very legitimate piece of testing - a kind of first-line defence. They're intended to test individual software modules for their low-level behaviour. Typically, a developer would be expected to run them before submitting any change or bugfix, as a kind of "smoke test" to make sure things are okay. Certainly, some organizations might make the mistake of thinking that this kind of testing is all that's required - which is dreadfully wrong - but I don't think there's anything hackish about it.
In a large organization, the testing team might not consider it testing because unit tests are necessarily maintained and performed by the developers only.
But I would argue the exact opposite with regards to underlining the difference between professional software development and hacking. If you don't have unit tests, I would say that what you're doing is closer to hacking.
Accountability on the heads of the powerful.
Power in the hands of the accountable.
How is the parent "insightful"?!
I wrote a 2300 word article for a column on Python! I didn't write a book. Well, actually, I did write a book, but it isn't the above article (and it's not about testing frameworks). It's certainly not a good idea to think my short article is the alpha and omega of testing. But I am confident that my article -does- address a topic that some Python programmers can benefit from. And other installments of _Charming Python_ each address similarly small, but useful, topics.
Buy Text Processing in Python