1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Automated web UI testing using Selenium with Python


Legacy applications are a fact of life in software development. However well a piece of software starts and no matter how much care is taken to document it, as people leave and new people are assigned to look after it, knowledge about what the software does or how it's meant to work is lost.

For older code which was written before a time of TDD and testable architecture this creates a fear of change, both for a developer and for the business. Testing is time consuming and manual and the knowledge of what the expected inputs and outputs of the application are, are lost and changed as ownership of the application changes hands.

In his book Working Effectively with Legacy Code Michael Feathers outlines steps which can be taken inside the code to refactor it and start adding test coverage. Depending on the size of the codebase and the budgetary and time constraints it can be difficult to get very far with refactoring the codebase itself.

A useful tool

While automated tests should also be used for new software they can be just as, if not more, useful when it comes to legacy software. For example, the UI of a legacy application tends to be much more fixed than for a project currently undergoing development.

Automated UI tests for a web application can provide a useful time-saver and allow you to quickly cover the application with regression tests at a higher level.

One of the most popular tools for automated UI testing is Selenium. Selenium offers support for a range of languages, including .NET, Java, Ruby, etc. With Selenium you can quickly script interaction with different browsers, primarily Firefox but there are also drivers available for Internet Explorer, Google Chrome and Phantom.

A natural fit

While the concept of Business Driven Development (BDD) is orthogonal to automation testing, the two work well together.

Even though BDD is about more than just a diferent way of coding, the Gherkin style Given, When, Then syntax is a good fit for UI tests. Since these Gherkin requirements often represent the outcome the user is expecting to see when they use the application they tend to align more naturally with UI testing.




I haven't blogged in a while, simply because I've not thought of any interesting topics to blog about, hopefully something will come along sooner or later!

In the meantime I'm promoting my little Visual Studio extension, PostHaste.

This extension aims to make sending code to hastebin (it's like a good version of PasteBin) from inside Visual Studio easier. Not that it could be much easier but it seemed like a fun way to learn Visual Studio extensibility.

It's (hopefully) compatible with Visual Studio 2013 and 2015, why not give it a try? :)

A screenshot of PostHaste in action.


MVC postback for users without JavaScript - Post 2


Posts in this series:

So far we have created a form which performs a postback to the server to add more input fields to the same page. We have encountered an issue with MVC seeming to cache partial views (or at least the values inside them).

Step 4

Step 4 attempts to fix the caching of the selected value field.

I spent hours looking for a way to stop MVC caching partial views, which is what I thought was happening. I tried disabling the output cache and loading the partial views via actions, neither of which helped. I finally found this answer on StackOverflow; the ModelState holds the old values when a view is reloaded via an HTTP POST even if you change the values of the model in the action.

By removing the specific value from the ModelState the value clears properly and the view displays as expected.

private ActionResult AddPostback(OrderViewModel model)
    model.SelectedMenuItem = null;

    return View("Order", model);

The form now works as expected, the "add another" button adds another input to the page by reloading the page, the submit button still submits the form to the server and redirects to the summary screen. Now we have the screen working for users without JavaScript however users get a "screen flicker" due to reloading the page when clicking "Add another".

See this image for an example of the screen flicker non-JavaScript users will see, this seems like an acceptable compromise, since there's no way to prevent the page having to reload for these users. However for people with JavaScript enabled it would be nice to offer a cleaner user experience.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17