Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming Software IT Technology Linux

Testing Frameworks in Python 120

Posted by Hemos from the smoothering-the-code dept.
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."
This discussion has been archived. No new comments can be posted.

Testing Frameworks in Python More

Testing Frameworks in Python

Comments Filter:
  • ...in Bret Pettichord's Scripting for Testers [pettichord.com] one day class.

    It talks about eliminating some of the tediousness from testing web applications, mainly by using automated solutions like WTR [rubyforge.org].

    He's also got a list of testing resources [io.com] that's got some good stuff in there...

  • 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.

    • Re:Different types of project ? (Score:5, Interesting)

      by kpharmer ( 452893 ) * on Monday April 12, 2004 @01:09PM (#8838942)
      > Please go an get a decent, non-language specific book on testing before reading and listening to this
      > article.

      Sure usability, user acceptance, system, string, and integration testing are all valuable. But why can't developers without any knowledge of these start with built-in unit testing?

      And keep in mind that few books on testing cover the fairly recent phenomenon of test-driven-development (or test-centered-development).

      The use of built-in test harnesses and focus upon developing tests as documentation of requirements is probably the biggest single improvement in testing in twenty years.

      In one fell swoop the debugger is rendered obsolete...
      • > probably the biggest single improvement
        > in testing in twenty years

        Right on. Being able to make some changes and run a suite of 500+ tests to make sure things still work is a thing of beauty.

        And when a bug slips through, that's just an opportunity to write another test and make sure that bug never happens again. Good stuff.
    • I agree that those topics are worthy of deeper discussion, but I think the article stands well on its own. I'm learning Python and I think the unittest section will help greatly while stumbling through the process of building applications.

      The links he provides in the Resources section at the end of the article provide well-rounded background information on testing in general.

      • I'm learning Python and I think the unittest section will help greatly while stumbling through the process of building applications.

        I've found that writing tests before writing the code they test requires a deal of self-discipline (ie. I don't do it as often as I should. When I have made this effort however, rather than stumbling through, the unittest module will took me by the hand and led me through.

        Running the test suite while writing really focuses you on a specific part of your code (ie. that par

    • 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.

      Yes, this is exacly what this article is about. What is wrong with that?

      No UAT, no System Test, no Integration Test... no how test cases should be defined.

      No it is assumed that anyone programmer worth his salt knows some test methodology, and this usefull article explains tools that make that task easier.

      Ple

    • Re:Different types of project ? (Score:5, Insightful)

      by Lulu of the Lotus-Ea ( 3441 ) <mertz@gnosis.cx> on Monday April 12, 2004 @01:56PM (#8839458) Homepage
      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.

    • Re: (Score:3, Informative)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion

  • Testing.. (Score:4, Informative)

    by MosesJones ( 55544 ) on Monday April 12, 2004 @01:05PM (#8838909) Homepage

    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.

    • Unit tests are just one aspect of testing (Score:5, Insightful)

      by DeadVulcan ( 182139 ) <dead.vulcan@nOspam.pobox.com> on Monday April 12, 2004 @01:43PM (#8839314)

      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.

    • Re:Testing.. (Score:4, Interesting)

      by Spoing ( 152917 ) on Monday April 12, 2004 @01:57PM (#8839465) Homepage
      1. 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.

      Agreed. I can impress someone with my knowledge and professionalism, but when they ask what languages I can program in and I state "I'm not a developer", they just don't get it. That I can whip a program up is one thing...that I know that I'm not the person to do that seems to lead to puzzlement.

      These days, testing (and CM) is so far off the radar for most folks that it is no longer considered an issue. Yet, developers are constantly required to know all details of the specs and to deliver code that does not immediately fall apart. Some can, but very few can do it rapidly.

      The extra burden of detailed testing -- work that the developers are usually not suited for or have time for anyway -- does not make for a productive environment. Limited testing is OK though full testing by development is a distraction -- both VV&T and development groups know it.

      That said, initial unit tests of the core services can be the responsibility of the development group, though it should never fall to the same person writing the code being tested. The unit test framework will be incomplete and faulty since the developer does not have the proper distance from the code they are testing.

      A skilled VV&T developer can do the job much better, though time for that person to write code to test the developer's work is usually not allocated in the schedule...even if such a person is hired at all.

      (Case in point: I was hired last year to automate testing and test 2 applications...10 months later, and here I am having tested about 20 applications and have not written any automated test sripts. Yes, I warned them that it takes a specific type of environment to support automated testing, one that can allow substantial amounts of time and effort to creating and maintaing those scripts, and I didn't see that environment. Yes, they understood and said 'do it anyway'. Yep, that worked.)

    • I see nowhere a claim that this article is meant to be a "be all and end all" statement on Software Testing.

      The posting and the article it links to are just what they claim to be.

      Software Testing is a whole different discipline, in its entirety, from software development. This does not negate the fact that unit and integration testing should first be performed by the developer, since they know their expected results.
      This article is "a good start" for information on Unit Testing Frameworks for Python.

      As a

    • Re:Testing.. (Score:3, Interesting)

      by SurfTheWorld ( 162247 )
      What is it about testers and their negative reactions to developers writing tests? Is it out of fear of job security? I don't understand why so many testers frown upon or discard tests written by developers as worthless, or second rate, to the tests that they have written. Indeed, many times what accompanies test dismissal is the comment of "Developers don't know how to test software." Nevermind the lack of supporting details to back up this broad generalization.

      What to me is so strikingly insane is th
      • What is it about testers and their negative reactions to developers writing tests? ... What are your criteria for considering a test valid or valuable? ... I would expect testers to gleefully accept developer unit tests.

        Hard-earned experience shows that it's risky to depend on developers to test their own code. It's kind of like playing a chess game with yourself. That said, I disagree with MosesJones's claim that unit testing is just hacking. It's an excellent part of a balanced breakfast. Ironically, i

  • Languages form an ecosystem (Score:4, Insightful)

    by Anonymous Coward on Monday April 12, 2004 @01:05PM (#8838911)
    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.

    • top of the foodchain (Score:3, Insightful)

      by Doc Ruby ( 173196 )
      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++/

  • Jython for unit testing (Score:5, Interesting)

    by Avumede ( 111087 ) on Monday April 12, 2004 @01:31PM (#8839170) Homepage
    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.

  • Why Python? (Score:1, Interesting)

    by sucati ( 611768 )
    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 kee

    • Re:Why Python? (Score:4, Insightful)

      by leshert ( 40509 ) on Monday April 12, 2004 @01:50PM (#8839386) Homepage
      A good point. The idea of reducing the number of lines of code isn't just to reduce the amount of typing--it's mostly to reduce the amount of code you have to _read_ to understand what's going on.

      For example, it's easier to see what's going on in:

      for line in file("/var/log/messages"):
      processLine(line)

      than in the equivalent C or Java code. Also, terseness isn't the ultimate goal--I could make this more terse (and less readable or efficient) by saying:

      [processLine(line) for line in file("/var/log/messages")]

      The biggest benefit of Python over Java, as far as I'm concerned, is that code written in Python looks like what it does--that's the source of the "Python is executable pseudocode" meme you often hear from Python fanboys. The lack of a compile step and the dynamic typing help, but they're secondary to me.

      • ITYM:

        for line in file("/var/log/messages"):

        processLine(line)
        • Correct. Slashdot's <ecode> tag ate the opening indent on the second line, and using blockquote made it ugly.

          Anyway, I figured anyone who read it would either have enough Java and Python experience to parse it, or too clueless to catch it. :-)

    • Re:Why Python? (Score:4, Informative)

      by dubious9 ( 580994 ) on Monday April 12, 2004 @02:09PM (#8839609) Journal
      First off, I had mod points and I feel bad about not modding you up, and you don't deserve a 0:offtopic score.But I though a responce would be better.

      Can someone help me understand why I would want to use Python as opposed to Java?

      Python is not just about brevity, but I think you underestimate writing less lines of code. Take the fact that if you are writing twice as much code, you're probably writing twice as many bugs. Also a consise 50K LOC program is much easier to get around in than a 200K program.

      But anyway, Python is an interpreted, interactive, object-oriented programming language. [python.org], where as Java is only the last of those three. Python also has dynamic documentation, meaning that the documentation string can be inspected at run-time, without the need to maintain a separate doc tree, ie Javadoc.

      Classes are dynamic ie. you can change their behavior at runtime. All python objects can be marshalled or serialized, while in Java you have to define the interface, and account for anything that you use that can't be serialized.

      There are also thing which I am indifferent about like tabbed blocks, and some things which I don't like, like not having enough compile time type checking. IMHO you should always define the type of a function parameter, it makes learning the API faster.

      In general, Python is great for script-strength stuff, ie. in situations where you would use perl. I can see it getting unwieldly as it got bigger but it generally scales much better then perl. Java tends to be too complex and too restrictive. In short there are many situations where you would choose one over the other.

      • In general, Python is great for script-strength stuff, ie. in situations where you would use perl. I can see it getting unwieldly as it got bigger but it generally scales much better then perl. Java tends to be too complex and too restrictive. In short there are many situations where you would choose one over the other.

        Python actually scales very well. I feel most people tend to think that it doesn't thanks to its "interpreted language" label. While the label is correct, the argument that it doesn't s

        • Well, the only reason I didn't think it wouldn't scale "well" (in comparision to Java) was that it didn't have static type checking which makes it harder to read APIs. However, I have seen less type error in Python than other languages with no static type checking.

          Also, my python programming isn't quite yet "pythonic" so my concerns are likely unjustified, and it does remain on my short list of implementation languages.
    • I'm not a Python person, but...I think the issue of 20 lines versus 3 has more to do with how efficient the code is, especially once it is translated into assembly. I think the basic question you ask is a good one, but your reasons for asking seem a little off the mark. Perhaps I am misunderstanding your point about lines of code? It doesn't seem to me that the amount of typing involved has anything to do with the Java vs. Python debate.
      • I'm not a Python person, but...I think the issue of 20 lines versus 3 has more to do with how efficient the code is

        Less lines of code != more efficient

        It boils down to what those lines of code are translated into. You can just as easily write a single line program which makes a library function call containing 50 machine instructions as you can write a 50 line assembly language program which gets converted to 50 machine instructions. Lines of code is not a good indicator of efficiency - not by a longs

    • Re:Why Python? (Score:3, Informative)

      by Daath ( 225404 )
      Try reading ESR's Why Python? [linuxjournal.com], also check out the Quotes on Python [python.org] from python.org :)
      It's a beautiful language, I'm sorry I can't code in it more...

    • 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.

      One of Python's great virtues is its readibility/maintainability. Python is not a terse language, if your really want to minimise line count (and decrease readibility) you'd do much better with Perl (which is not to say that you cannot write readible Perl). In fact part of Python culture is the eschew the one-liner.

  • Here is a presentation, with PDF article, about integrating the two approaches, straight from recent PyCon:

    Literate Testing: Automated Testing with doctest [python.org]

Slashdot Top Deals

"If it ain't broke, don't fix it." - Bert Lantz

Close