GNOME Platform Stormclouds

Posted Mar 28, 2004 22:57 UTC (Sun) by mly (guest, #2171) [Link]

Writing a comprehensive set of unit tests is realistic only for easily-definable portions of your program.

I've used the term Unit Test the way it's been used in Extreme Programming. These tests are not complete functional tests for the program in question. They test small units (typically classes) in isolation. Their aim is to assert that a piece of code does what the programmer inteded. They are rarely functionally complete, but often exercise every line of the unit under test, and then they will find everything that the compiler would, and many other things. See http://www.c2.com/cgi/wiki?ProgrammerTest

Functional testing on a system level is an interesting subject, but it has nothing to do with static typing or the lack thereof.

Even if your surprising claim of "several times more code" were true...

Is that controversial? Just a few examples:

• Glyph Lefkowitz rewrote Twisted in Python and went from 20000 lines to 3000 lines.
• Greg Stein reported that rewriting eShop in Python led to 90% fewer lines than C++.
• Bruce Eckel, author of Thinking in C++ and Thinking in Java reports a tenfold productivity gain with Python.

I'm sure there are many situations where the improvement is much smaller, the study by Prechelt I referred to before had smaller differences, but it showed more than 50% reduction in lines of code and developer time, as well as fewer bugs.

...given the length of each of your replies to this story...

I wish I was able to explain things more briefly. It's not a skill I have I'm afraid. :( It impresses me when people can get the same message through in 50 words that I need 250 for, but at least I can do that stunt in code! :)

...I'm surprised that you should be so afraid of a few more keystrokes.

• Fewer lines of code means fewer bugs. Many studies verify this.
• Fewer lines of code means that it's easier to understand the program.
• Fewer lines of code means shorter development time. This has also been verified many times. Less time spent coding means more time to test, rewrite bad parts and relax. I.e. better program, happier programmer.

All this naturally assumes that the fewer lines of code comes from using a language which lets you use a higher level of abstraction (or from finding a simpler solution to your problem). Every seasoned C or C++ programmer knows that squeezing too much code into one line will make debugging much harder, and that it's better to use a few lines more. That might make it hard to think that another language will allow you to reduce development time and bug count while making you type much less, but it works. Just like C was a big step forward from assembly language, Python was a big step forward from C.

Among the actively used and developed languages, Python stands out as a language where readability and ease of use and learning has a high priority in its design. It's not without warts, but it's a lot better than most, even if several others reach the same level of abstraction.

have you ever released a project that demonstrates your approach to unit testing?

SystemSpecifyer is publically available at sourceforge (see also www.systematik.se). I haven't been involved for a year, but there are few checkins since then. It's a rather odd piece of software though, and it has dependencies to particular versions ZODB and wxPython, but if you want have a look at it, go ahead. It's far from perfect, but the unit test were very helpful to me.

I wrote unit tests into Trestlemail 4 years ago.

Did you write the tests before you wrote the code to test? For me that makes a big difference. I've never managed to catch up with unit tests if I rushed ahead and wrote working code before the tests. This will then come back and haunt me when I need to change the code and don't have tests that show me at once when I break things. I'm not sure extreme programming works well in all situations, but I think they are right about writing the tests first. Among other things, it makes you write programs that are testable! Having the focus on testing from the start makes a difference.

There is much more to do on the subject of testing, and I think this is a very interesting subject, but we've strayed far off the issue of GNOME now.

Suffice to say that many project show that it's possible to write dependable software in Python. That Python is one of three permitted languages on the floor of the New York Stock Exchange and that it's used to plan space shuttle launches for NASA also suggest that you can write fairly reliable code with it.