2
\$\begingroup\$

This helper method is designed to make stubbing ICommands simpler.

Do you see any problems with this implementation?

public static ICommand GenerateCommandStub( Action<object> executeAction = null, Func<object, bool> canExecuteFunc = null) { var commandStub = MockRepository.GenerateStub<ICommand>(); commandStub.Stub(command => command.Execute(Arg<object>.Is.Anything)) .Do(executeAction ?? (_ => { })); commandStub.Stub(command => command.CanExecute(Arg<object>.Is.Anything)) .Do(canExecuteFunc ?? (_ => true)); return commandStub; }
\$\endgroup\$
0

1 Answer 1

Reset to default
3
\$\begingroup\$

It looks fine to me, although I would personally prefer to have method chaining rather than optional parameters just for semantic purposes. Are your arguments meant to be weakly typed (using object)? If I could, I would change that to something strongly typed, but that is out of scope for this question.

\$\endgroup\$
5
  • \$\begingroup\$ This looks like ICommand from WPF, which is weakly typed. \$\endgroup\$ Commented Aug 22, 2014 at 16:53
  • \$\begingroup\$ Ah yes. I've never used WPF, so I didn't know \$\endgroup\$ Commented Aug 22, 2014 at 17:03
  • \$\begingroup\$ The Execute and CanExecute methods ICommand interface both accept an object instance, so I think that's what should be used here. Nice idea with the method chaining. It adds some complexity, but it makes it nicer for the consuming code. \$\endgroup\$ Commented Aug 25, 2014 at 14:59
  • \$\begingroup\$ Psst - it's method overloading ;) \$\endgroup\$ Commented Sep 3, 2014 at 2:53
  • \$\begingroup\$ Actually, I meant currying + overloading ;) Ie, f(x) -> g(x, y) \$\endgroup\$ Commented Sep 3, 2014 at 7:29

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.