I’ve implemented a new, cleaner simpler, ninja-deluxe-shiny-gold-plated-ultra-cool way of configuring fakes/stubs/mocks in FakeItEasy.
The news are two fold:
- Simpler call specifications
- Simpler argument validations
How’s this for simple?
public void Example() { var serviceProvider = A.Fake<IServiceProvider>(); var service = A.Fake<IWidgetFactory>(); A.CallTo(() => serviceProvider.GetService(typeof(IWidgetFactory))).Returns(service); }
No need for awkward lambda expressions where you have to split the configured method from the object that it’s called on.
Instead of:
serviceProvider.CallsTo(x => x.GetService(typeof(IWidgetFactory))
This reads better:
A.CallTo(() => serviceProvider.GetService(typeof(IWidgetFactory)))
As I mentioned argument validation has also become simpler, I mean, this is just childs play isn’t it?
A.CallTo(() => serviceProvider.GetService(A<Type>.Ignored)).Throws(new Exception()); A.CallTo(() => serviceProvider.GetService(A<Type>.That.Matches(_ => _.Name.StartsWith("A")))).Throws(new Exception());
The really cool thing is that you can define your own extension methods that provides validations for arguments, these extension will show up on the “That”-property, like this:
A<Type>.That.IsValidatedByMyVeryOwnExtensionMethod(); A<Type>.That.IsInSystemNamespace(); A<string>.That.SpellsMyName();
It can be whatever you want, this means that you can effectively provide your own DSL for argument validation.
I’m thinking about providing an “An” class as well so that you can write the more grammatically correct “An<object>.Ignored” rather than “A<object>.Ignored”, but I’m not sure it’s worth it, maybe it’s confusing, what do you think?
I’ll be blogging about argument validations and how to provide your own extension super easy soon.
No comments:
Post a Comment