But I noticed something strange: some columns were blank when I pasted them into Excel (or notepad). The blank columns were always DataGridTemplateColumn and that made sense. How could it know what to copy from one or more controls?

Turns out this is really easy to fix if you are using data binding. All you have to do is bind the ClipboardContentBinding property on the DataGridTemplateColumn with the value you want copied for this column.

For example:

1
2
3
4
5
6
7

<data:DataGridTemplateColumn Header="Name" ClipboardContentBinding="{Binding Name}" SortMemberPath="Name">
  <data:DataGridTemplateColumn.CellTemplate>
     <DataTemplate>
        <HyperlinkButton Content="{Binding Name}" Margin="3" />
     </DataTemplate>
  </data:DataGridTemplateColumn.CellTemplate>
</data:DataGridTemplateColumn>

And that’s it. Control+C copy works as desired.

VisualSVN Server: http://www.visualsvn.com/server/
Ankh SVN (plugin for Visual Studio): http://ankhsvn.open.collab.net/

Hudson Continuous Integration: http://hudson-ci.org/

Fitnesse (.NET/SLiM): http://www.fitnesse.org/ and http://www.fitnesse.org/FitNesse.DotNet

You can always message us on twitter @jwcarroll and @benfarmer.

While I would argue you should begin your TDD journey by writing your own mocks; using a framework will certainly make like easier in many instances and allow you to focus on the tests themselves.

I was a RhinoMocks guy for a long time, but have recently converted to Moq… AND I LOVE IT!!! Moq is simple and easy to use, and doesn’t get in the way of the intent of your tests. That being said, there are certain scenarios you run into with any framework that you end up coding around, and sometimes that does get in the way of your what you trying to say with your test.

Moq allows for a pretty simple syntax when you want to set up a return value on a mocked type.

1
2

var mockService = new Mock<IReturnStuff>();
mockService.Setup(svc => svc.SomeMethodCall()).Returns("Hello, World!");

Pretty sweet so far, and that works 99% of the time. But… what about a scenario where we want to return different values on successive calls to that method. I can think of a lot of situations where, in the absence of formal eventing, you want your code to test some value until it meets a certain criteria. You might be polling a web service for status updates, or checking a database to see if a record has been written. Whatever the case may be, it will come up.

So, for illustration purposes, let’s make up one such example. Suppose we wanted to ask a service for a specified set of values, but the return types could be varied. Perhaps we only care about some subset of those values, and want to test that our code correctly deals with variable data.

We have our service contract:

1
2
3
4

public interface IReturnStuff
{
    String ReturnAString();
}

Next we have our consuming class (the subject under test):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

public class UsesReturnedStuff
{
    public IReturnStuff ReturnStuff { get; set; }
    private Regex Filter { get; set; }
 
    public UsesReturnedStuff(IReturnStuff returnStuff)
    {
        ReturnStuff = returnStuff;
        Filter = new Regex("(the|quick|brown|fox|hello|world)(:Pu)?", RegexOptions.IgnoreCase);
    }
 
    public List<String> GetStuff(Int32 times)
    {
        var stuff = new List<String>();
 
        for (var i = 0; i < times; i++)
        {
            var newStuff = ReturnStuff.ReturnAString();
 
            if(Filter.IsMatch(newStuff))
                stuff.Add(newStuff);
        }
 
        return stuff;
    }
}

As you can see we have a pretty basic setup here that uses a white-list approach to building up a list. We want to write some tests to mock this behavior. If we wanted two different return values when this method is called, we might instinctively write a test like this:

1
2
3
4
5
6
7
8
9
10
11
12
13

[Test]
public void LastSetupWins()
{
var mockReturnStuff = new Mock<IReturnStuff>();
var usesStuff = new UsesReturnedStuff(mockReturnStuff.Object);
 
mockReturnStuff.Setup(svc => svc.ReturnAString()).Returns("Hello");
mockReturnStuff.Setup(svc => svc.ReturnAString()).Returns("World!");
 
var stuff = usesStuff.GetStuff(2);
 
Assert.AreEqual("Hello World!", String.Join(" ", stuff.ToArray()));
}

If you couldn’t already tell from the name of the test method, this won’t work as the last return value to be Setup wins. The output from this test will produce the text:

“World! World!”

Not so great, but the Moq documentation gives us a workaround by using a callback method. A little bit of refactoring and Voila!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

[Test]
public void SetupWithCallback()
{
    var mockReturnStuff = new Mock<IReturnStuff>();
    var usesStuff = new UsesReturnedStuff(mockReturnStuff.Object);
 
    var returnValues = new[] {"Hello", "World!"};
    var numCalls = 0;
 
    mockReturnStuff.Setup(svc => svc.ReturnAString())
        .Returns(() => returnValues[numCalls])
        .Callback(() => numCalls++);
 
    var stuff = usesStuff.GetStuff(returnValues.Length);
 
    Assert.AreEqual("Hello World!", String.Join(" ", stuff.ToArray()));
}

Here we are taking advantage of anonymous methods and closures to essentially keep feeding our Mock service it’s next value. This works, but… yuck! Reading this test is not very clear, and it gets in the way of the intent.
Since we are supposed to refactor our test code too, lets move the ugly bits out into a private method, and re-write our test again.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

private static Int32 SetupMany(Mock<IReturnStuff> mock, Expression<Func<IReturnStuff, String>> expression, params String[] args)
{
    var numCalls = 0;
 
    mock.Setup(expression)
        .Returns(() => args[numCalls])
        .Callback(() => numCalls++);
 
    return args.Length;
}
 
[Test]
public void SetupWithExtractedMethod()
{
    var mockReturnStuff = new Mock<IReturnStuff>();
    var usesStuff = new UsesReturnedStuff(mockReturnStuff.Object);
 
    var calls = SetupMany(mockReturnStuff,
                          svc => svc.ReturnAString(),
                          "Hello", "World!");
 
    var stuff = usesStuff.GetStuff(calls);
 
    Assert.AreEqual("Hello World!", String.Join(" ", stuff.ToArray()));
}

This is good. We haven’t lost any functionality, but the intent of the test is much clearer. There is less friction because you can read the code and understand what it is doing pretty quickly without having to “decipher” the meaning.
Now, this is all fine and good, but I am likely to run into this same scenario more than once. What I would really love to have is a SetupMany() method that was built into Moq. A method I could call directly on the mocked object. Well… starting with C# 3.0 Extension Methods give us the ability to do just that. With a little work, we should be able to create a very generic extension to give us the desired behavior.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public static class MoqExtensions
{
    public static void SetupMany<TSvc, TReturn>(this Mock<TSvc> mock,
        Expression<Func<TSvc, TReturn>> expression,
        params TReturn[] args)
        where TSvc : class
    {
        var numCalls = 0;
 
        mock.Setup(expression)
            .Returns(() => numCalls < args.Length ? args[numCalls] : args[args.Length - 1])
            .Callback(() => numCalls++);
    }
}

Ok, so I know the method signature looks pretty scary. Just don’t stare at it long enough or you will go blind! The extra bit with the Ternary operator is a bit of error checking to prevent you from running over the bounds of the array. If you call the method more times than available arguments, it will simply keep returning the last argument in the list.
Refactoring our test one last time gives us an even cleaner syntax that works with any return type. The second test merely demonstrates the “sticky” final value being returned over and over.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

[Test]
public void SetupWithGenericExtensionMethod()
{
    var mockReturnStuff = new Mock<IReturnStuff>();
    var usesStuff = new UsesReturnedStuff(mockReturnStuff.Object);
 
    mockReturnStuff.SetupMany(svc => svc.ReturnAString(), "Hello", "World!");
 
    var stuff = usesStuff.GetStuff(2);
 
    Assert.AreEqual("Hello World!", String.Join(" ", stuff.ToArray()));
}
 
[Test]
public void SetupWithLotsOfParams()
{
    var mockReturnStuff = new Mock<IReturnStuff>();
    var usesStuff = new UsesReturnedStuff(mockReturnStuff.Object);
 
    mockReturnStuff.SetupMany(svc => svc.ReturnAString(),
                              "the","quick","brown","fox","jumps","over","the","fence","hello!");
 
    var stuff = usesStuff.GetStuff(11);
 
    Assert.AreEqual("the quick brown fox the hello! hello! hello!", String.Join(" ", stuff.ToArray()));
}

And there you have it. Extending the Moq API without having to actually go in and modify the source. Hopefully this will save you a headache or two in the future.

Chaos to Awesome in 60 minutes / the heart of Agile without all the fluff

Track / Area: Developer / Methodology

Technology: Agile, CI, testing, development processes, tools

General / Specific Experience Level: Beginner / Beginner

Co-Presented with Josh Carroll.

Want to increase visibility, collaboration, and communication in your development process? Striving to ensure higher quality products with rapid feedback cycles? Don’t know where to start?

Our goal is to show you how we use simple tools and practices to work in an agile way – without any fluff. We will cover how we manage our task board and source code; simple continuous integration; unit testing with mocks; design patterns for clean separation of concerns and testability. All in one hour. ‘Cause that’s how we roll.

You can check out all the details on the CodeStock session page.

So you read it, right?

Whatever. I know you didn’t read it. I have Google Analytics and it’s telling me a different story.

Well, since you didn’t read his post, I’ll distill it down to fit your impatience. An agile team can be taken over by a single, forceful, individual in one of two ways: (1) being confidence, charismatic, and passionate about their idea and reasoning until it wins or, more subliminally, (2) using their social influence to gain a majority on the team and use that to make sure their idea is chosen.

Can this happen to a team? Uh, yeah. Does this happen? I would say so.

Obviously, the issue is that agile teams contain human beings. That’s mistake number 1. What were they thinking?

Sure, a team consists of people and we’re flawed. However, I think there are checks and balances built into agile/scrum to help prevent this from happening. Here are four lines of defense, as I see them.

First line of defense: The Team. Each team member has the responsibility to listen to and help each other. It’s not about one person winning or being the star. However, we become lazy, passive, unwilling to step up and contend. It’s hard work after all. You have to show up and make an effort. Every day. Besides, the arena of ideas is a dangerous place. What will people think of me? What if I don’t have the best idea? Complacency is easy. I’d much rather do that.

Second line of defense: Scrum Master. The scrum master is a facilitator. It’s their responsibility to make sure all team members are engaged in the conversation. They need to create balance by knowing each team member: who to draw out and who to prevent from shutting down discussion. They also need to keep it on point and on time. It’s a very difficult job.  And who really wants to do that all the time? Why does it have to be hard? Maybe no one will notice…

Third line of defense: Product Owner. The product owner needs to be assisting the scrum master in facilitation. When the scrum master is absent (physically or de facto), the product owner must step in and provide the missing facilitation.  But there are so many other things to worry about. And, really, let’s be honest, it’s more than a little below what I should really be doing.

Fourth line of defense: Management. Management is really the first and last line: after all, the buck stops with them. They are responsible for bringing in exceptional people and creating teams with the critical mass to succeed. There are times they will have to make difficult decisions with team changes or helping people move on to a “better fit” (i.e. fire them). Good leadership is hard to find. Who wants to be a leader when you can be a celebrity? Planning, vision, difficult decisions, dealing with all the problems: blah! Who wants that? I’ll take a triple frapalattemocha with cinnamon and some non-dairy whipped cream with just a pinch of sprinkles to go. Yeah, now that’s something I can enjoy.

“Management” is not a universal cop-out for the problems that exist.

Each of us need to be leaders and take ownership on our team. We can try to claim ignorance or find excuses when the team fails but, ultimately, it will be our fault if we don’t do our part.