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."
...in Bret Pettichord's Scripting for Testers one day class.
It talks about eliminating some of the tediousness from testing web applications, mainly by using automated solutions like WTR.
He's also got a list of testing resources that's got some good stuff in there...
The Army reading list
Despite all of Guido Van Sustren's claims to the contrary, Python's garbage collector just doesn't work correctly, allowing the programmer to create a circular reference which never gets resolved. This is a critical impediment to writing mission critical applications in Python, as they will eventually run out of memory and fail.
Python is an excellent beginner's language, well-suited to replace Visual Basic or possibly even Perl for many tasks. But testing about unit testing before we address a fundamental design flaw such as memory leakage is tantamount to putting the cart before the horse. Python's memory issues need to be fixed before the language can break out of its niche.
Call me silly here, but that article talks about developer ONLY testing, and doesn't seem to discuss different types of projects at all. This was about basic code testing, and mainly unit-test.
No UAT, no System Test, no Integration Test... no how test cases should be defined.
Please go an get a decent, non-language specific book on testing before reading and listening to this article.
An Eye for an Eye will make the whole world blind - Gandhi
A few thoughts:
1. I've never had a problem with memory management in python. Can't say it doesn't exist, just never impacted my production applications.
2. Implementing great built-in test frameworks doesn't need to wait for memory management improvements. I'm seeing almost immediate pay-offs from this kind of built-in testing.
3. I'm implementing python as an alternative to java in large applications - with complete success. Easy to learn, easy to maintain, fast enough to handle millions of rows of data a day - what's not to like?
I hate to break it to the hack and slashdot crowd, but Testing is actually a whole career in itself, and the application of different testing processes and methods to different projects is a critical part of ensuring projects succeed.
This article covers NOTHING about the different types of testing on a project, or indeed how test cases should even be constructed. Its basically about some UnitTesting elements that could be done by testing.
I know its unpopular here on Slashdot to claim that there are more developers working on big projects than people hacking in Python. Buts its articles like these that underline the difference between professional software development and hacking.
This is about hacking.
An Eye for an Eye will make the whole world blind - Gandhi
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 obviously made up the developer's name "Guido Van WHAT???" and your claims about leakage are complete crap. We've had up to a dozen coders working on a single project at my organization, and we've hit 20KLOC without a single memory leaking problem: that tends to be reserved for our C apps. I think you're just a copy-'n'-paste troll who's trying to spread FUD about Python. Yeah, yeah, IHBT, whatever.
For using a niche language, Portage sure seems pretty popular.
I use Jython regularly for unit testing Java. The expressivness of jython is great for writing shorter unit tests, and the lack of compilation makes the whole write-test-debug cycle short. And, dare I say, it's just more fun to code in jython than Java.
dip switches are the only way to program
Can someone help me understand why I would want to use Python as opposed to Java? I've read several articles touting how concise Python is e.g. for what takes 20 lines in Java, can be done in 3 lines in Python. This argument just doesn't hold water. Am I to believe that us coders are that slow at typing? And we don't have modern IDEs that handle source code generation? And most importantly the bulk of development time should be spent in design and problem solving, not typing, right? We should also keep in mind the reality that we as programmers make mistakes and typing a few extra characters to improve code readability/maintainability may not be at that bad of an idea.
yo man, I was just joking. Personally, I test all my code and very thoroughly so don't worry about me. And i do not think I am too good, actually I do not think I'm good at all. So again, I was just joking and maybe I should have put a ":)" at the end to drive that home but meh.
Can you write a customized HTTP server with sed,awk and grep?
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 does his braino reference to the poisonous Greta Van Sustern in any way detract from the merits of his argument about the language? This isn't a celebrity deathmatch between tcopeland and van Rossum. Is your complaint the tip of the sharkfin, as a new class of "strawman ad hominem" inversted criticism surfaces on Slashdot? Debaters play the ball, not the man.
--
make install -not war
> There is nothing, and i do mean NOTHING that a real Unix professional can do with Python or Perl
> that he or she can't do with awk, sed, and grep.
And there is nothing a that a real Unix professional can do with awk, sed and grep that cant be done with emacs.
But then, there is nothing that cant be done with emacs.
Norman Cook's Ode to Sl
"...There is nothing, and i do mean NOTHING [,] that a real Unix professional can do with Python or Perl that he or she can't do with awk, sed, and grep..."
Humm, that doesn't sound too practical and portable for many cases. I take it you would also need bash or something to go with those tools. And heaven forbid if someone else has to maintain the code after you on a large-scale project.
Unfortunately you had to use HTML to render an outline, when you'd have used PostScript if you had a choice. The reality of programming is the necessity of working with other people, including programmers thinking in the paradigm of the moment (think 1990s Perl), graphic designers/artists with Flash on the brain, marketers with buzzword colored glasses, legacy systems, and customers seeing their businesses modeled explicitly for the first time in any terms. I'd prefer compiling everyone's flowcharts to C++/IDL/VHDL, but that environment is at least 5 years away. Meanwhile, all we have it this year's hammer, and everything looks like a nail.
--
make install -not war
Technology is for medieval primates. Real results need nothing more than a verbal, somatic and material component, in a TV studio.
"Any technology, sufficiently advanced, is indistinguishable from a rigged demo." - Luke McCormick
--
make install -not war
Here is a presentation, with PDF article, about integrating the two approaches, straight from recent PyCon:
Literate Testing: Automated Testing with doctest
>>I hate to break it to the hack and slashdot crowd, but Testing is actually a whole career in itself,
You were looking for mention of this in an article about Python unit-testing?
I am sure the programmers that read this page respect their testers.
Knock that chip off your shoulder.
The title of the article makes me think of QMTest, an actual testing framework written in Python.
You know, the funny thing about this is that a good coder must want to see their code actually run, right? After all, everyone wants immediate gratification. And the beauty of unit tests is it provides just that... you can actually run your code in a controlled environment easily without the need to start up an entire application/framework/etc. This is especially true of large and/or distributed applications where there's a great deal of overhead in running a full system test.
Moreover, unit tests make the test-develop cycle a *lot* shorter, especially on large projects, since you can easily run your code. Thus, you're wasting less time testing and more time coding... sounds like a great deal to me!
So, in my mind, any coder that doesn't feel like writing tests isn't, in fact, a particularly good coder. Or, perhaps, they're doing their job for all the wrong reasons. I code because I want to see the fruits of my labour, and unit tests are a great way to quickly and easily see the results of my work.
I've written an extension of unittest that adds random unit testing in the style of Haskell's QuickCheck: pickcheck.
Actually, one almost certainly *could* write a "customized HTTP server" with awk (and you wouldn't even need sed and grep). It's a Turing-complete langauge.
Just thought you might want to know.
ERROR 144 - REBOOT ?
how about just :
map(processLine, file("/var/log/messages"))
or if processLine is set to return 1 for error and 0 for okey-dokey :
l = filter(processLine, file("/var/log/messages"))
BitTorrent is also written in Python.
If you think you are too good to write tests, then perhaps you are too good for the software industry?
But just about ideal for being a CEO or a politician:
Programmer: If it compiles, it works!
CEO: If the share price goes up before end of quarter, it works!
Politician: If it get's my face on TV, it works!
You can see the slashdot crowd's level of interest by just comparing the number of comments to those on other stories.
This kind of rubbish is only of interest to stupid academics who like drawing boxes inside other boxes and call it research. Then these peons make me sit stupid exams on ir where I have to draw the damn boxes again, while yapping about all this object orientated rubbish.
Just because a language is Turing-complete doesn't mean it can do everything, just that it's capable of computing everything. I imagine an awk program might have some difficulty acquiring a socket to a network interface; establishing connections to hardware that communicates using electrical signals isn't exactly a computational problem in the usual sense.
I do not like that I cannot expect to look at a Python function definition and see what are the expected types of the arguments.
If you could, ie if the functions did expect arguments to be of certain types, you couldn't use polymorphy in python, could you? In fact it can (has) been argued that particularly in large projects, type restrictions lead to lack of maintainability.
Probably the answer is to rely on unit testing instead of static typing for large application maintainability in python.
There are httpd's written in pretty much every language -- although I don't think BrainF*ck has been used yet. And Malbolge certainly hasn't.
I had to laugh at the moderation results for the parent post, pointing out that debate targets the stated ideas with counterideas, not the people stating them with mere negation:
Starting Score: 1 point
Moderation -1
100% Overrated
Karma-Bonus Modifier +1 (Edit)
Total Score: 1
Sharkbite!
--
make install -not war
Yes, I wish I was part of the "intellignet" around here.... How do I connect to that net, I want to be proud too!!!