•
•
•
•
I gave a talk at pycon 2008 dealing with testing, code coverage, complexity and how to know when you are "done" testing. Though the talk was given at a Python conference, and the examples are in python, the talk is actually a general discussion of d
I thoroughly enjoyed Jon Udell's interview with Ward Cunningham on IT Conversations. They talk a lot about Ward's efforts at the Eclipse Foundation to build transparent workflow systems. That is, as Jon puts it:
But what if you could find out, before pressing the Save button, what's going on in that black box? And what if your way of finding out wasn't by reading bogus documentation, but instead by probing the system itself using its own test framework?From Ward Cunningham's Visible Workings « Jon Udell
Referenced Thu Mar 20 2008 08:42:43 GMT-0600 (MDT)
You'll want to read Jon's description of Ward's visible workings along with the podcast to get the most out of it. Better yet, I'd love to have a screencast of the system at work.
At one point Jon and Ward talk about how this might apply to eGovernment. Think about a button you could push at any point that would tell you how your current interaction with a government Web site was likely to proceed. I'd love to see it.
Tags: testing programming workflow itconversations egovernment
I put together a mini-lecture on unit testing in Scheme for my CS330 class. It's not a complete introduction, just a tutorial on getting started. If you have suggestions on using SchemeUnit, I'd love to hear them.
Students in CS330 submit their assignments to an autograder. They sometimes try to use the autograder as a test harness with bad results.
I think there are some distinct advantages to students using unit testing in preparing their assignments:
On the last point, while I'm happy to have them share tests, I don't want to provide them. I want them to get experience in writing tests. Discussing tests with other students is a great way for them to learn.
Tags: cs330 scheme programming testing
I didn't grow up in an era where testing was as well though of as it is now. When I learned to program, you ran a few tests after the fact and threw it over the wall to the QA department. Not very politically correct in today's software engineering world.
As a result, I understand the value of testing and support the idea intellectually, but I don't have the discipline.
Recently I was faced with the problem of building code that translated a domain specific language (KRL) back and forth between three different representations:
The textual representation is what people read and write. The JSON representation is what machines (other programs) will read and write. The abstract syntax (a Perl data structure) is what will be interpreted.
I quickly realized that getting this right--and convincing myself of that--would require something more than some ad hoc testing. So, I decided to mechanize.
I knew that Perl had testing facilities--anyone who's built a library has seen that. So, I had to figure out how they worked. I found these resources handy:
Here's what I did:
I also added test scripts for each module in the system as well as a few scripts to check for developer issues--thanks to petdance (PDF).
I used the petdance smoke script to run all the tests in Test::Harness. I modified the petdance rule.t script to check for Perl programming best practices like always having use strict at the front of every Perl program in the collection.
I also wrote a use.t script that goes through the entire collection of Perl modules and programs, gathers a unique list of every library they use, and then checks for availability on the current machine.
Now, I can flesh out this framework with other tests as they come to me or I run into problems. It feels good.
Tags: testing programming perl kynetx
I'm giving an introductory talk on testing tomorrow for Utah Python. I'm planning to cover unittest, doctest, coverage and interpreting coverage results. At the end will be a hands on session for applying what we've learned. We'll write a simple p
Some interesting thoughts about testing and python found among gnome developers. Joe Shaw was explaining how most new gnome apps these days are written in either python or C#. They choose C# for their app (a href="http://www.beagle-project.org/"
Testing Tools Panel I've blogged about bugs and testing in open source previously, so I was quite interested in this panel. I was surprised because there was little discussion of code coverage, because I think it is quite important for dynamic lang