August 30, 2010
I’ve had Twill on my list of technologies to look at for a couple of years now. I finally had the chance to use it today and have been mightily impressed so want to share my thoughts.
For those not aware, Twill is a scripting language implemented in Python for web browsing. Using the command line or scripts, you can interactively or programmatically access websites.
Twill’s core language is simple and readable, which is just what I wanted. It can be easily hooked into Python and unittest if I desired that functionality in the future.
Let’s say I have a Django development server running on my local machine and I want Twill to go to a particular URL and check I have an HTTP status returned of 200:
go http://127.0.0.1:8000/search/genre code 200
That’s it: clear and readable. If the status isn’t 200, Twill will raise an error and report the code it actually received.
One thing I need to do with my tests is check for the presence of certain HTML elements, to ensure things like forms and headings are being set correctly:
find '<h2 class="heading">Jazz</h2>'
Here I’m checking that I have the heading Jazz present in the current URL loaded. Again, if this condition is not met, Twill will raise an appropriate error message.
Am I sure a valid form submission is working correctly and redirecting me to the right URL? If I set the genre field of the form named search_form to the value “grindcore”, and then submit the form I can then verify the returned URL is what I expect it to be:
formvalue search_form genre grindcore submit code 200 url http://127.0.0.1:8000/genre/grindcore
The 200 is possibly superfluous, but it adds a little extra confidence that things are working okay.
I’m not one for things which bring in lots of dependencies, provide a high barrier to entry or get in the way of the task at hand. Twill is painless to install, quick to learn and enables readable web tests to be written quickly and easily using just a plain old text editor. It might lack the functionality of tools like Selenium, but the Python API provides an easy way to extend its capabilities if desired.
Go take a look: http://twill.idyll.org/
August 12, 2010
The subject came up yesterday about counting bits. I remembered the subject from university in the context of error checking, but I couldn’t remember the specifics during the conversation. It was only later that I recalled the subject of Hamming values or weights, and from there I tracked down an algorithm by Brian Kernighan (or Peter Wegner, or Derrick Lehmer). For fun, I translated the C source to Python to yield the following:
def bit_count( v ): c = 0 while v > 0: v &= v - 1 c += 1 return c
For a bit of practice, I then opted to convert into Erlang:
bitcount(V) -> bitcount(V, 0). bitcount(0, C) -> C; bitcount(V, C) -> bitcount( (V band (V - 1)), (C + 1)).
I could probably roll the two arity 2 clauses into one, but this is a minor habit from my old Prolog days and I always feel it looks a bit cleaner than opting for a case statement. Feel free to disagree.
Since Clojure is my “language for 2010″, and I’ve been rather slack on keeping up with it lately:
(defn bit-count ([v] (bit-count v 0) ) ([v c] (if (zero? v) c (recur (bit-and v (dec v)) (inc c)))))
This feels like it could be expressed more functionally, dropping the two argument version for a compact one-argument version. This might be an interesting exercise for when I have a spare moment, unless someone out there already has a solution?
Just thought I’d share….