Posts about Python

Unit Testing Redux

Thinking back over my post from a year ago, I find that the real reason for most bad unit tests is that people are trying too hard, typically for one of the following reasons:

  • Some folks have drunk the "don't repeat yourself" KoolAid: I agree that not repeating code is a virtue in most cases, but unit test code is an exception: cleverness in a test both obscures the intent of the test and makes a subsequent failure massively harder to diagnose.

  • Others want to avoid writing both tests and documentation: they try to write test cases (almost invariably as "doctests") which do the work of real tests, while at the same time trying to make "readable" docs.

Read more…

Avoiding Temptation: Notes on using 'unittest' effectively

Avoiding Temptation: Notes on using 'unittest' effectively

Goals

The goals of the kind of testing outlined here are simplicity, loose or no coupling, and speed:

  • Tests should be as simple as possible, while exercising the application- under-test (AUT) completely.
  • Tests should run as quickly as possible, to encourage running them frequently.
  • Tests should avoid coupling with other tests, or with parts of the AUT which they are not responsible for testing.

Developers write such tests to verify that the AUT is abiding by the contracts the developer specifies. While an instance this type of test case may be illustrative of the contract it tests, such test cases do not take the place of either API documentation or of narrative / "theory of operations" documentation. Still less are they intended for end-user documentation.

Read more…

Phillip Eby: Python Is Not Java

Phillip chats about the problems for which Java programmers naturally turn to XML, and Python programmers to .... Python.

I particularly like Phillip on using XML:

XML is not the answer. It is not even the question. To paraphrase Jamie Zawinski on regular expressions, "Some people, when confronted with a problem, think 'I know, I'll use XML.' Now they have two problems."

This is a different situation than in Java, because compared to Java code, XML is agile and flexible. Compared to Python code, XML is a boat anchor, a ball and chain. In Python, XML is something you use for interoperability, not your core functionality, because you simply don't need it for that.

60,000 Lines of Javascript!!

Harry Fuecks blogs about an interesting survey of "recurring problems in projects using dynamic languages"

At the other end of the scale there's developers who know a language well and can't resist adding 'smart' features. That needs to be a golden rule of what not to do with dynamic languages - don't extend the language (at least not using the language itself).

He talks mainly about Javascript and PHP, but then points at a "nasty bit of cleverness using Python's shiny new decorator syntax."

AMK's Journal: Python Archives

Andrew writes:

The reduction in complexity from having higher-level things in the library was very impressive. In contrast, I find the new language features added in 2.4 unimpressive and not likely to be useful to me.