I tend to spend all my coding time nowadays plagued with guilt. I try to be a good developer and refactor the code, after running the tests, after writing the code, after running the tests, after writing the tests. But in the interests of getting any code written at all, I end up skipping between one and all of these steps (generally not the writing code part).

If this sounds like you, I cannot recommend Fixie strongly enough.

It's a low ceremony test framework that presents the minimum possible barrier to entry for the guilt driven tester/developer.

Positives

Fixie is so nice for a few reasons. Firstly it's self contained. After installing from NuGet, the Visual Studio test runner for Fixie is already set up.

This means you don't have to locate the correct package for your Visual Studio version. If you're lazy like me then you'll appreciate this time-saver.

To install from the package manager console use:

Install-Package Fixie

Or search "fixie" on the NuGet package manager.

The next point in its favour is your tests are just code. While MSTest and to some extent NUnit are an alphabetti spaghetti of attributes which challenge you to remember the difference between your [TestFixture] and [TestClass] attributes, Fixie requires no attributes to start working.

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? :)

Posts in this series:

• Post 1
• Post 2

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)
{
    ModelState.Remove("SelectedMenuItem");
    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.

Posts in this series:

• Post 1
• Post 2

Despite only around 1.2% of users having JavaScript disabled there is still a requirement to develop sites which work for users who have JavaScript turned off, especially sites which provide government services. The UK's Government Digital Services (GDS) require that a site works without JavaScript and is then enhanced using JavaScript. This causes all sorts of problems designing forms, especially where there is an "Add more" option for input fields.

Designing something like an "Add more" functionality with JavaScript is fairly trivial, having it work for those without is less so. Having encountered this problem several times I've written a summary of the approach I have used to address this.

The code

All the code for this tutorial is available on GitHub. I have used Git's branches to take snapshots of development changes. The final code is in the branch "step-5". Additonally I have hosted the website on Azure so you can see what the final page does here.

The product

We are designing a page to allow users to choose items from a menu, once they have selected as many items as they want, they submit the form and are taken to a summary of their active orders: