Out of the different Source Control options Git is definitely the one most worth learning, however, it's also one of the most confusing.

With that in mind I'm going to add to the crowded market of "Git beginners" tutorials. Hopefully given that I can still remember the struggle of learning it and that my current level of understanding probably rates as "simpleton" this will be a useful tutorial.

I'm going to be writing for Git on Windows and will try to assume no existing knowledge beyond knowing what a file and folder is. Because of this I'm going to make a lot of oversimplifications.

Install It

Use the download link here or Google "Windows Git" and click the first link.

After using the installation defaults, you're done.

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.