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."
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.
> 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...
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.
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.
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.
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.)
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
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 that at the most primitive levels, testers write tests. What kinds of tests they write vary in size, scope and purpose. Developers, through unit tests, are technically doing part of the the tester's job. They produce tests! Sure, they are unit tests, but they are still valuable from the standpoint of software verification. Even if a tester walks away from them with simply a better understanding of how the software is put together, does that not make them valuable or important?
Too many times do testers toss away unit tests as worthless (or in Moses' case "hackish") simply because they were not written by a tester. Tell me what qualifications you must have to be a tester and to write tests. What are your criteria for considering a test valid or valuable? Now tell me how I can run the litmus test against my test to see if it passes what you consider to be the qualifications for inclusion into a suite of tests.
Were the best interests of the project (not the individual) ranked at the top of the importance list, I would expect testers to gleefully accept developer unit tests. Not only do they show accuracy in the software, but they more importantly demonstrate a developer's willingness to test and prove functionality. "Here's my code, it implements requirements X, Y, and Z, and here are the unit tests that demonstrate the functionality." Given that, a tester needs to tie together a high level interaction test or execute the regression tests. But the developer has gone a long way to help out the tester, and more times than not the tester pushes back with some assinine comment like "developers don't know how to write tests."
Successful software teams are not like the 4x2 tetris block, where the design team hands off UML to the developers to implement, who then hand off the code in an assembled version to the testers to verify. Successful software teams are a coagulation of the + tetris blocks where developers perform some requirements analysis and testing while at the same time coding. Testers pick up some system administration. And system administrators do some testing and even development. This type of cross-pollinated structure on a team keeps code velocity high, job competition to a minimum, and leads to higher overall satisfaction (generally speaking, of course
Your view of unit tests as hacks without the proper overall test plan shows your inflexibility to cohabitate with developers willing to test on your project. Archaeic views like this usually lead to unsuccessful projects. Take a moment to look back over your resume and reflect on the various software projects you've worked on. Ask yourself what developement environment existed, and if the project was successful. My guess is you'll notice a pattern.
Do it for da shorties