TempData & ViewBag Support

[AlexArchive]

Earlier today I had to write a unit test against the TempData property and wondered if there was any support in this library for this - there is not.

The problem that I have is that TempData is basically weakly typed and casting is not elegant_. I love the way this library enables strong typing when possible and thought It *might_ be awesome if there was some support for this.

Because there would already be support for TempData I guess it would make sense to have a ViewBag counterpart too.

I am not entirely convinced as to how valuable this feature would be nor am I confident about what the syntax might look like, but I thought I would throw it out there for discussion anyway.

*It is not so much that I find casting inelegant but rather - I use this library for all my controller tests and I find that altering between this library and standard tests does not look fluent and consequently, neat.

[robdmoore]

In terms of adding ViewBag support and an idea of a syntax for it check out: #4

In terms of a syntax for TempData I guess we need to have an extension method off of the controller since we can't chain that check off the ActionResult or any of the subsequent objects.

Maybe something like (?):

    _controller.ShouldHaveTempDataProperty<string>("key")
    _controller.ShouldHaveTempDataProperty<string>("key", "value")
    _controller.ShouldHaveTempDataProperty<string>("key", s => s.EndsWith("ue"))
    _controller.ShouldHaveTempDataProperty<string>("key", s => { Assert.That(s, Is.EqualTo("value"); })

[AlexArchive]

I strongly recalled reading an issue about view bag support but when I skimmed both the open and closed issues I could not see it - I thought I must be mad! Turns out it was a pull request ugh.

Oh wow. That syntax looks superb Rob.

Unless somebody else wants to take this on, I will work on this soon.

[robdmoore]

Ha! Happens to the best of us :P

I suspect nobody is on this so feel free :)

[AlexArchive]

It occurred to me that we could enable syntax like this:

[Test]
public void Delete_ExistentPost_ReturnsMessage()
{
    // Regular method on ControllerResultTest<T>.
    controller
        .WithCallTo(c => c.Delete(""))
        .ShouldHaveTempDataProperty<string>("Message")
}

This is different from your proposed solution:

[Test]
public void Delete_ExistentPost_ReturnsMessage()
{
    controller.Delete("");

    // Extension method on Controller. 
    controller
        .ShouldHaveTempDataProperty<string>("Message");
}

The benefit of this proposed solution is consistency with the rest of the API.

The drawback however, is that when you want to perform multiple logical assertions, the syntax is less than nice:

[Test]
public void Delete_ExistentPost_RedirectsToIndexWithMessage()
{
    controller
        .WithCallTo(c => c.Delete(""))
        .ShouldRedirectTo(c => c.Index);

   // Regular method on ControllerResultTest<T>.  Eww. 
   controller
        .WithCallTo(c => c.Delete(""))
        .ShouldHaveTempDataProperty<string>("Message")        
}

This is different from your proposed approach:

[Ignore]
public void Delete_ExistentPost_RedirectsToIndexWithMessage()
{
    controller
        .WithCallTo(c => c.Delete(""))
        .ShouldRedirectTo(c => c.Index);

    // Extension method on Controller. 
    controller
        .ShouldHaveTempDataProperty<string>("Message");    
}

I am on the fence about which approach to take. Which do you prefer?

[robdmoore]

I prefer what I suggested just because it means we aren't needing to invoke the method twice. Thoughts?

On 9 Sep 2014, at 10:35 pm, ByteBlast notifications@github.com wrote:

It occurred to me that we could enable syntax like this:

[Test]
public void Delete_ExistentPost_ReturnsMessage()
{
// Regular method on ControllerResultTest.
controller
.WithCallTo(c => c.Delete(""))
.ShouldHaveTempDataProperty("Message")
}
This is different from your proposed solution:

[Test]
public void Delete_ExistentPost_ReturnsMessage()
{
controller.Delete("");

// Extension method on Controller. 
controller
    .ShouldHaveTempDataProperty<string>("Message");

}
The benefit of this proposed solution is consistency with the rest of the API.

The drawback however, is that when you want to perform multiple logical assertions, the syntax is less than nice:

[Test]
public void Delete_ExistentPost_RedirectsToIndexWithMessage()
{
controller
.WithCallTo(c => c.Delete(""))
.ShouldRedirectTo(c => c.Index);

// Regular method on ControllerResultTest. Eww.
controller
.WithCallTo(c => c.Delete(""))
.ShouldHaveTempDataProperty("Message")
}
This is different from your proposed approach:

[Ignore]
public void Delete_ExistentPost_RedirectsToIndexWithMessage()
{
controller
.WithCallTo(c => c.Delete(""))
.ShouldRedirectTo(c => c.Index);

// Extension method on Controller. 
controller
    .ShouldHaveTempDataProperty<string>("Message");    

}
And so I am torn. What do you think?

—
Reply to this email directly or view it on GitHub.

[AlexArchive]

I was leaning that way too so yeah, all good.

I will start on this now.

[AlexArchive]

How do you want to handle multiple tests?

_controller.ShouldHaveTempDataProperty<string>("a")
_controller.ShouldHaveTempDataProperty<string>("b")

_controller
    .ShouldHaveTempDataProperty<string>("a")
    .ShouldHaveTempDataProperty<string>("b")

_controller
    .ShouldHaveTempDataProperty<string>("a")
    .AndShouldHaveTempDataProperty<string>("b")

[mwhelan]

Probably with an And, so that you can just reuse assertions rather than creating And versions of each. Fluent Assertions uses And that way. Here is an example from Fluent Assertions:

action
   .ShouldThrow<RuleViolationException>()
   .WithMessage("change the unit of an existing ingredient", ComparisonMode.Substring)
   .And.Violations.Should().Contain(BusinessRule.CannotChangeIngredientQuanity);

So your example above would be:

_controller
    .ShouldHaveTempDataProperty<string>("a")
    .And.ShouldHaveTempDataProperty<string>("b")

[robdmoore]

That seems reasonable.

On 10 Sep 2014, at 12:45 am, Michael Whelan notifications@github.com wrote:

Probably with an And, so that you can just reuse assertions rather than creating And versions of each. Fluent Assertions uses And that way. Here is an example from Fluent Assertions:

action
.ShouldThrow()
.WithMessage("change the unit of an existing ingredient", ComparisonMode.Substring)
.And.Violations.Should().Contain(BusinessRule.CannotChangeIngredientQuanity);
So your example above would be:

_controller
.ShouldHaveTempDataProperty("a")
.And.ShouldHaveTempDataProperty("b")
—
Reply to this email directly or view it on GitHub.

[AlexArchive]

I do not understand the purpose of the And. here :c Can somebody explain?

Especially because elsewhere in the library we do this:

controller
    .WithCallTo(c => c.Index())
    .ShouldRenderDefaultView()
    .WithModel<string>()
    .AndModelError("foo")
    .AndModelError("bar");

[robdmoore]

Maybe just make the new extension return the controller and leave it at that?

ByteBlast notifications@github.com wrote:

I do not understand the benefit of the And. here :c Can somebody explain?

Especially because elsewhere in the library we do this:

controller
.WithCallTo(c => c.Index())
.ShouldRenderDefaultView()
.WithModel()
.AndModelError("foo")
.AndModelError("bar");
—
Reply to this email directly or view it on GitHub.

[AlexArchive]

That would conform to the syntax I described earlier:

_controller
    .ShouldHaveTempDataProperty<string>("a")
    .ShouldHaveTempDataProperty<string>("b")

Especially easy to implement but not very fluent, wouldn't you say?

[robdmoore]

You could have an AndShouldHaveTempDataProperty method that is a synonym too?

On 10 Sep 2014, at 6:32 am, ByteBlast notifications@github.com wrote:

That would conform to the syntax I described earlier:

_controller
.ShouldHaveTempDataProperty("a")
.ShouldHaveTempDataProperty("b")
Not terribly fluent, wouldn't you say?

—
Reply to this email directly or view it on GitHub.

[AlexArchive]

That would enable syntax like this though, would it not?:

_controller
    .AndShouldHaveTempDataProperty<string>("a")
    .ShouldHaveTempDataProperty<string>("b")

We could perhaps return a TempDataTestResult that has the AndShouldHaveTempDataProperty method. What do you think?