I went to three talks in the morning session, which were loosely centered around the theme of testing and extreme programming:
Extreme Programming with Python in the Classroom
Michael Weigend
Michael's students in Germany used Python to create an English text editor for grade school students and a chat room program. They used XP concepts like user stories, big visible charts, test-driven development, and small iterations. One interesting bit of teaching methodology: Michael taught his students simple GUI programming techniques by just giving them pieces of working source code and letting them explore. I thought this was great, because it mirrors the way most kids learn to use computers in general (start using this thing, and see what happens). GUI code is especially well-suited to this, due to the visual feedback, and Python sweetens the deal, since the visual feedback is so immediate.
py.test and the py lib
Holger Krekel
PyTest was started because the unittest module was "unpleasant" to extend. It's currently used in the PyPy project, among others. Holger made a couple of main points about PyTest:
Agile Testing with Python Test Frameworks
Grig Gheorghiu
This was a grab-bag talk that gave us a quick look at a lot of Python testing frameworks, most of which looked pretty neat, and many of which I'd never heard of before. I'll try to come back and turn these into hyperlinks. For now, here are there names, and short descriptions of the cooler ones he demoed:
Extreme Programming with Python in the Classroom
Michael Weigend
Michael's students in Germany used Python to create an English text editor for grade school students and a chat room program. They used XP concepts like user stories, big visible charts, test-driven development, and small iterations. One interesting bit of teaching methodology: Michael taught his students simple GUI programming techniques by just giving them pieces of working source code and letting them explore. I thought this was great, because it mirrors the way most kids learn to use computers in general (start using this thing, and see what happens). GUI code is especially well-suited to this, due to the visual feedback, and Python sweetens the deal, since the visual feedback is so immediate.
py.test and the py lib
Holger Krekel
PyTest was started because the unittest module was "unpleasant" to extend. It's currently used in the PyPy project, among others. Holger made a couple of main points about PyTest:
- PyTest itself is external to your code. The metaphor is that it is running against your code. So unlike unittest, you're not responsible for invoking the test code within your test.
- There are some neat features like test generators, which are generator functions that generate more tests. PyTest then runs all of these generated tests.
- He emphasized the user-friendly stack traces in PyTest, which did look nice.
- Finally, he spoke a bit about other parts of py.lib, including py.execnet, which allows you to send snippets of Python code elsewhere via SSH, popen, etc. to execute remotely.
Agile Testing with Python Test Frameworks
Grig Gheorghiu
This was a grab-bag talk that gave us a quick look at a lot of Python testing frameworks, most of which looked pretty neat, and many of which I'd never heard of before. I'll try to come back and turn these into hyperlinks. For now, here are there names, and short descriptions of the cooler ones he demoed:
- PyLint
- coverage
- buildbot
- PyUnitPerf, which adds time and load constraints to unit testing.
- FitNesse, which allows the user to specify test inputs and expected outputs via simple HTML tables (even generated via a wiki, as they were in his example).
- Selenium, which is a Javascript-based tool that uses your real web browser to execute scripted tests on the web. (Seemed kind of like Greasemonkey, but for testing). You can watch your browser zip through the test, step quickly or slowly, etc. It was very impressive to see.
- Mentioned that Jython is enjoying a lot of popularity for testing Java code (all the advantages of Python for testing, but the main body of your code stays in Java).
- Recommended avoiding an "automation cathedral." You should have exactly the amount of daily test automation that your current needs dictate.
- Finally, pointed us to his blog on agile testing.
Comments