.Net

Dropdown list with MVC5.1 – now out of the box!

.Net, MVC, Templating, , , View all 5 comments

Last year I made this post showing a clean way to render a dropdown list in MVC.

Recently MS released MVC5.1 (prerelase) and excitingly it now has Enum support.

Jon Galloway has written an excellent post outlining this change. The .Net team have added a new HTMLHelper extension called EnumDropDownListFor that will render an Enum as a dropdown box (or radio button list).

How does this compare to the long winded solution I outlined last year, I hear no one asking?

To recap, we want to render a dropdown list that looks like:

EditPageFinal

with our view rendering our model with one line. 

@Html.EditorForModel()

We no longer need the custom Htmlhelper Extension EnumDropDownListFor used in the previous solution, as that now ships with MVC5.1 (well, not the same implementation!). We do, however, still want to be culture aware and use a Resx file to contain the resources of the actual names to display on screen. I’d now recommend using display attributes in the Enum to identify the resource. This will leave our Enum and model looking like:

public enum AirlinePreference
{
    [Display(Name = "AirlinePreference_BritishAirways",
                ResourceType = typeof(Resources.Enums))]
    BritishAirways,
    [Display(Name = "AirlinePreference_EasyJet", 
                ResourceType = typeof(Resources.Enums))]
    EasyJet,
    [Display(Name = "AirlinePreference_RyanAir",
                ResourceType = typeof(Resources.Enums))]
    RyanAir,
    [Display(Name = "AirlinePreference_Virgin",
                ResourceType = typeof(Resources.Enums))]
    Virgin
}

public class PersonViewModel 
{
    [Display(Name="First Name")]
    public string FirstName { get; set; }

    [Display(Name = "Last Name")]
    public string LastName { get; set; }

    [Display(Name = "Airline Preference")]
    public AirlinePreference? AirlinePreference { get; set; }
}

For reference our resx file looks like this

Enums

Compile it, run it, go to the Add Person page and you’ll see the dropdown list as before…

5.1 is still prerelease and at the time of writing @Html.EditorForModel will not render an Enum dropdown list. It currently needs a push in the form of an Enum template (as described in Jon’s blog) to know how to display an Enum.
With my lean hat on, for the purpose of this blog the following will suffice.

Create a view called Enum.cshtml and put it in the EditorTemplate folder

enumtemplate

Add this one line

@Html.EnumDropDownListFor(x => x)

Now go the Add Person page and voila, a DropDownList is present.

Advertisement

Write Less, Test More (part 2)

.Net, agile, c#, Data Driven Testing, TDD, Testing, Uncategorized, XBehave, XUnit, , , , , View all 3 comments

In my previous post I blogged about Xunit Theories, which provided a neat way to pass multiple test scenarios into one test method. Why I’m liking Xunit these days is due to its extensibility. In particular Adam Ralph and friends have extended it and come up with Xbehave.Net.

A popular pattern when testing is Given (my input), When (I test this), Then (expect this outcome). See Cucumber scenarios for more info. One of the problems with my last post is that the [Fact] didn’t use this language. The test output didn’t use this language. Wouldn’t it be nice if it did?

If we wrote that test with xBehave it would. This post revisits the problem from the first post and shows how we could test it using xBehave.Net.

Problem Recap

I want a class that, when given a sentence, will return a collection of strings containing all words in lowercase. This collection should only have alpha characters in it – i.e. spaces and punctuation are to be ignored.

To write our test for the zero case, using xBehave it could look like:

[Scenario]
public void FindWordsEmptyStringScenario(string input, IEnumerable output)
{
"Given an Empty String"
   .Given(() => input = string.Empty);

"When I find words in this string"
   .When(() => output = _wordFinder.FindAllWordsInLowerCase(input));

"Then I expect the answer to be an empty list"
   .Then(() => Assert.Empty(output));
}

Cucumber uses scenarios, so does our test. The test method, takes as its inputs an input and output variable. The method cleanly has three calls, each coming off a string describing the action:
Spelling it out, the Given() sets up our input variable.
When(), does the business of calling our method under test, returning the output, into our variable, called output.
Then(), asserts if the output is what we expected.

Talk about readable!

It gets better – run this through reSharper and our output looks like:

zero_xunit

Again very readable I think.

As I’m sure you guessed, this framework supports something very similar to Xunit’s [InlineData]. It has examples.

Our test scenario, with all example inputs and outputs, based on first blog, looks like

[Scenario]
[Example("", new string[0])]
[Example("One", new [] { "one" })]
[Example("One two", new[] { "one", "two" })]
[Example("One...:; - ,two", new[] { "one", "two" })]
public void FindAllWordsInLowerCaseScenario(string input, string[] expectedOutput, IEnumerable output)
{
    "Given the sentence '{0}'"
        .Given(() => { });

    "When I find words in this sentence"
        .When(() => output = _wordFinder.FindAllWordsInLowerCase(input));

    string.Format("Then I expect the answer to be [{0}]", string.Join(",", expectedOutput))
        .Then(() => Assert.Equal(expectedOutput, output));
}

What’s nice here is that if you remember the outputs from the InLine tests – it didn’t output the expected string arrays’ content. Here, as the method name that gets generated for the test runner output is simply a string we can manipulate the string to show the contents of the expected array.

all_xunit

Each example provided effectively creates a new scenario, which are grouped in the output by scenarioNumber.StepNumber.

For the output names to be neatly formatted here (without repetition of the input variables) we are setting the attribute [OmitArgumentsFromScenarioNames] on the class, which suppresses them.

Write Less, Test More (Part 1)

.Net, c#, Data Driven Testing, TDD, Testing, XUnit, , , , , , One comment

Just like my software development skills, my approach to writing tests over the years has changed, but it’s only recently I’ve started to use more than the basic Assert functionality of testing frameworks.

This post explains an approach I used to test a particular module that came about through TDD and how to test a number of scenarios, by writing just one test method.

The problem

I want a class that, when given a sentence, will return a collection of string containing all words. This collection should only have alpha characters in it – i.e. spaces and punctuation are to be ignored.

My tests

As I’m dealing with a collection I think it makes sense that my method should cope with an empty sentence, a sentence with one word and a sentence with n words. At least one of these n word sentences should be peppered with some non alpha characters.

A reasonable approach might be to setup my test class, then write my first test to test the ‘0’ case. This could look like:

[Fact]
public void GivenAnEmptyStringWhenFindAllWordsExpectAnEmptyList()
{            
    var expectedResult = new string[0]; 

    var result = _wordFinder.FindAllWordsInLowerCase(string.Empty);

    Assert.Equal(expectedResult, result);
}

(Where _wordFinder is the class under test. This test asserts that an empty collection is returned from FindAllWordsInLowerCase method).

Run the test – it’ll fail. Go off create a WordFinder class, with the method FindAllWordsInLowerCase(string input), write the code to return an empty string list

Re-run the test and hopefully the test will pass.

Great. Next test is the scenario with one word. Forget DRY; copy and paste previous test, rename it, change the inputs and expected output and rerun. 

[Fact]        
public void GivenOneWordWhenFindAllWordsExpectOneItemInLowerCase()
{
    var expected = new List<string> { "one" };
            
    var result = _wordFinder.FindAllWordsInLowerCase(OneWord);

    Assert.Equal(expected, result);
}

Write some code to get this to pass, then, copy and paste test class again, alter inputs and expected outputs… you get the idea.

This will work and is an approach I’ve used for a while. The outcome is great – we’ll have a class with very high coverage that was developed just as our tests informed it. For me though, I prefer to be a bit more DRY than this.

Cue…. Xunit Theories

In a nutshell, an XUnit Theory, is a means to perform a data driven test. Data is provided in an [InlineData(…)] attribute. Each InlineData attribute applied to a Fact, will result in  a different test.

Define your test method and define your theory’s data and you can run multiple inputs and test the expected outcomes through a lot less methods – one in this case! Putting this into practice, our two previous tests now look like:

 [Theory]
 [InlineData("", new string[0])]
 [InlineData("One", new[] { "one" })]        
  public void FindAllWordsInLowerCaseTheory(string input, IEnumerable<string> expectedOutput)
  {
     var result = _wordFinder.FindAllWordsInLowerCase(input);

     Assert.Equal(expectedOutput, result);
  }

And when run with ReSharper, produces an output that looks like:

resharp21

Unfortunately it can’t output expectedOutputs cleanly when it’s a collection, but we have a test that’s DRY and easier to read from a non technical perspective. Potentially a non developer could even provide these inputs and outputs, lending itself to BDD very nicely.

You can also achieve a similar result with nUnit, using it’s [DataSource] attribute.

As we are using XUnit, I suspect it may be possible to modify the output behavior, so that it can display the expected collection of strings better. Not in scope for this post though.

So finally, when all our test scenarios are created our code looks like:

[Theory]
[InlineData("", new string[0])]
[InlineData("One", new[] { "one" })]
[InlineData("One, two", new[] { "one", "two" })]
[InlineData("ONE,4--;@@ ::tWo", new[] { "one", "two" })]
[InlineData("paulthecyclist tested; PaulTheCyclist failed @#$@! PaulTheCYclist Coded, paulthecyclist tested => PaultheCyclist passed!", new[] { "paulthecyclist", "tested", "paulthecyclist", "failed", "paulthecyclist", "coded", "paulthecyclist", "tested", "paulthecyclist", "passed" })]
public void FindAllWordsInLowerCaseTheory(string input, IEnumerable<string> expectedOutput)
{
    var result = _wordFinder.FindAllWordsInLowerCase(input);

    Assert.Equal(expectedOutput, result);
}

This produces five tests. I think it’s easier to read than having a test class with five separate methods and certainly less code to write/copy and paste.

There is an even more fun way to write your tests using XUnit though, which addresses the readability of the output along with other things, that I’ll cover in part 2.