13 Sep 2010, 08:21
Generic-user-small

Juan Pablo Perez (2 posts)

When I test the method Should_Create_Topic_And_Notify_The_User I get the following error in ReSharper:

Expected: collection containing But was: < , , >

The completed code for the method is:

    [Test]
    public void Should_Create_Topic_And_Notify_The_User()
    {
        var professionalDevelopment = new Topic
                                      {
                                          Id = 3,
                                          Color = ColorTranslator.FromHtml("#00000"),
                                          Name = "Professional Development"
                                      };

        var formValues = new FormCollection
                             {
                                 {"Id", professionalDevelopment.Id.ToString()},
                                 {"Name", professionalDevelopment.Name},
                                 {"Color", professionalDevelopment.ColorInWebHex().Trim('#')}
                             };
        var controller = new TopicController();
        var result = (RedirectToRouteResult)controller.Create(formValues);
        
        Assert.Contains(professionalDevelopment, Topic.Topics);
        Assert.That("Index", Is.EqualTo(result.RouteValues["action"]));
        Assert.That("Your topic has been added successfully.", Is.EqualTo(controller.TempData["message"]));
     }

I know the error is caused by Assert.Contains(professionalDevelopment, Topic.Topics); but I don’t know the reason.

¿Could anybody help me to resolve the problem?. Thank you in advance.

Juan

13 Sep 2010, 14:55
Headshot_pragsmall

Jonathan McCracken (35 posts)

Juan,

Try a couple things. First make sure that Equals() is working properly for your Topic object. You can add a break-point to the Equals() method in Topic when debugging the test to see what is not equal or where your equals method is causing the problem. If that doesn’t fix it try this:

Verify that you are clearing the Topic.Topics collection in every test. You can do that by adding the following to your setup fixture:

[Setup]
public void setup()
{
Topic.Topics = Topics = new List<Topic>
              {
               new Topic {Id = 1, Color = Color.Red, Name = "Work"},
               new Topic {Id = 2, Color = Color.Blue, Name = "Home"}
              };
}

This will make sure that your Topic.Topics collection is reset every time you run the test and the static list isn’t becoming a side effect.

Hope that helps,

Jonathan

15 Sep 2010, 08:58
Generic-user-small

Juan Pablo Perez (2 posts)

Jonathan,

What I did to resolve the problem is create the Equals() method just as it is in GetOrganizedFinal project.

By the way, I have some problems with that project (GetOrganizedFinal) to open it with Visual Studio 2010. Do you have a version of the project for VS 2010 that we could download it?

Thank you very much for your help. I keep reading and practising with book.

Juan

03 Oct 2010, 10:00
Generic-user-small

Mark Pawelek (1 post)

I got the same error.

The best way to resolve it is to set up debugging for NUnit. First ensure that NUnit is loading a new dll each time. With NUnit open, Tools, settings, Assembly Reload, Set these: Reload before each test run : yes Reload when test assembly changes: yes

Set a break point in the test.

With VS2008 open, Debug, Attach to process: GetOrganized.Tests.dll - NUnit.

Now just run the test from NUnit. It will stop at the break point.

It was failing on the line:

Assert.Contains(professionalDevelopment, Topic.Topics);

Because professionalDevelopment was not the same as the item in the Topics list. You can edit the code to fix the minor difference.

20 Oct 2011, 17:36
Generic-user-small

Brian Cook (1 post)

In version 1.0 of the book, this is a bug due to confusion between named colors and un-named colors. The color assigned to the topic is created as a named color (Color.Black) and thus the ColorTranslator.ToHtml function returns “Black” not “000000”. This causes the TopicController.Create code to prepend “#” to “Black” yielding “#Black” which of course fails to parse.

The simplest solution is to normalize the color handling so that none of the colors are treated as named colors and the ColorInWebHex() function never returns a color name.

This change to Topic.Color property does the trick:

    public Color Color
    {
        get { return _color; }
        set 
        { 
            // force all colors to be explicit ARGB, not named
            if (value.IsNamedColor)
            {
                _color = Color.FromArgb(value.ToArgb());
            }
            else
            {
                _color = value;
            }
        }
    }

    private Color _color;

I notice in the downloaded code, Jonathan cheated and got around this by passing ColorTranslator.FromHtml(“#000000”) instead of Color.Black. Personally I like being able to not worry about using named colors.

  You must be logged in to comment