Skip to main content

Selenium is usable and I'm very happy

I always thought Selenium is hard to use and doesn't worth my time. So in the past, I used twill to create a script (python) that would go the site, filling in any forms and did all tests that I would normally do by hand. It's a life saver. You don't want to fill in the large HTML form by hand every time you need to test your app. Using twill, I can just press the Enter key and it will run all tests I want. I can even go take some drink and snacks while the tests is running and get back to see whether it success or not.

But there's one downside with twill, you need to crafts all the test script by hand, looking at each form field you need to fill in. So this time I think it's time to start looking back at Selenium. All cool guys out there are using it to test their applications, it shouldn't be that hard. There's 2 parts of Selenium (actually it's more than that but for now I'd only interested in that 2 parts):-
  • Selenium IDE - Firefox addons that allow you to record your interaction with the browser.
  • Selenium RC - Consists of a server (java application) running on (by default) port 4444 and a client that would connect to the server, open up your browser and running up the test case specified. The client available in few languages - Python, Ruby, PHP, .Net etc.
The cool part is the IDE allow you to export the test case into client language so in the end I can still have something like twill. This is the coolest part. The other cool part is the python client is just a single module that I can copied to my PYTHONPATH and it just work. Now I feel like hugging all my kids and wife telling them, see ... now Selenium is working for me ! Too bad they are all sleeping now ;)

The 'not-so-cool' part, it doesn't work with Javascript popup calendar so you have to enter the date by hand.

Comments

Popular posts from this blog

PHP with docker

A friend asking about a PHP library and I decided to test whether that library is working. But I don't have PHP environment setup (we're Python shop btw). But thanks to docker, that's easy these days. docker run -it --tty --rm --volume $PWD:/app --user $(id -u):$(id -g) composer require google/apiclient:^2.0 Then we just need to create the script to run, still in the same directory:- include_once __DIR__ . '/vendor/autoload.php'; $GCSE_API_KEY = "nqwkoigrhe893utnih_gibberish_q2ihrgu9qjnr"; $GCSE_SEARCH_ENGINE_ID = "937592689593725455:msi299dkne4de"; $client = new Google_Client(); $client->setApplicationName("My_App"); $client->setDeveloperKey($GCSE_API_KEY); $service = new Google_Service_Customsearch($client); $optParams = array("cx"=>self::GCSE_SEARCH_ENGINE_ID); $results = $service->cse->listCse("lol cats", $optParams); And we can run that script again using docker:- docker run -it --...

The first step in learning new programming language

Is to prepare the basic environment where you can freely try and experiment with the new language features and tools. Maybe because I'm not programmer type person, but more as tinkerer/builder, I hate learning the language syntax and stuff. For years after I started "learning" Python, I can't barely write any Python code. But I have manage to try lot of Python cool apps because I have that environment for me to experiment with all Python based applications. All these cool apps that get me hooked to the language, not the syntax or whatever language features. And in my experiences, this is one reason why people failed to get hooked on the new language they want to learn. They started learning with some of the language syntax and eventually get bored, because not so much interesting stuff there. In whatever programming language, it's the ecosystem that made it lively, and where the real work happened. Early this year, I made it a point to learn Go programmin...

AI coding tools fragmentation

Executive Summary The discussion centers on a tweet by DHH (David Heinemeier Hansson) from January 10, 2026 , arguing against the fragmentation of AI coding tools. DHH contends that developers do not want a separate CLI for every model provider (e.g., Anthropic’s Claude Code, OpenAI’s tools). Instead, he advocates for a unified interface —specifically citing OpenCode —that allows developers to swap models within a single environment. The thread reveals a three-way tension in the developer community between convenience (unified tools), corporate control (walled gardens), and sovereignty (running local models). Key Discussion Themes 1. The Fatigue of Fragmentation The Problem: Developers are exhausted by "model choice fatigue" and the need to manage multiple CLIs. As Rob Zolkos noted, the fragmentation is absurd, leading some to write scripts just to manage their AI CLIs. The Desire: There is a strong consensus (DHH, Will McGugan, Mustafa Ergisi) that a "universal s...