So I’m sure people could work out the generalized implementation of Mark’s suggestion but I thought I’d post it for comments. I’ve created a generic ParameterNameSpecimenBuilder based on Mark’s LifeSpanArg: public class ParameterNameSpecimenBuilder<T> : ISpecimenBuilder { private readonly string name; private readonly T value; public ParameterNameSpecimenBuilder(string name, T value) { // we don’t want a … Read more
Use the RepeatCount property: var fixture = new Fixture { RepeatCount = 9 }; var actual = fixture.Create<string[]>(); // -> The ‘actual’ array is 9 items now. or fixture.CreateMany<string>(9).ToArray()
The answer provided by Nikos Baxevanis provides various convention-based ways to answer the question. For completeness sake, you can also do a more ad-hoc build: var phoneBook = fixture.Build<PhoneBook>().Without(p => p.AllContacts).Create(); If you want your Fixture instance to always do this, you can Customize it: fixture.Customize<PhoneBook>(c => c.Without(p => p.AllContacts)); Every time that Fixture instance … Read more
As answered here you can have something like public class FooArg : ISpecimenBuilder { private readonly string value; public FooArg(string value) { this.value = value; } public object Create(object request, ISpecimenContext context) { var pi = request as ParameterInfo; if (pi == null) return new NoSpecimen(request); if (pi.Member.DeclaringType != typeof(Foo) || pi.ParameterType != typeof(string) || … Read more
You’ll have to create your own InlineAutoMoqDataAttribute, similar to this: public class InlineAutoMoqDataAttribute : InlineAutoDataAttribute { public InlineAutoMoqDataAttribute(params object[] objects) : base(new AutoMoqDataAttribute(), objects) { } } and you’d use it like this: [Theory] [InlineAutoMoqData(3,4)] [InlineAutoMoqData(33,44)] [InlineAutoMoqData(13,14)] public void SomeUnitTest(int DataFrom, int OtherData, [Frozen]Mock<ISomeInterface> theInterface, MySut sut) { // actual test omitted } Note that … Read more
In short, AutoFixture.AutoMoq is an extension that turns AutoFixture into an Auto-Mocking Container using the Moq dynamic mock library. There’s also a similar extension for AutoFixture that enables auto-mocking with Rhino Mocks. This article introduces auto-mocking for AutoFixture: http://blog.ploeh.dk/2010/08/19/AutoFixtureAsAnAutomockingContainer.aspx. Here’s a couple of follow-ups: http://blog.ploeh.dk/2010/08/25/ChangingTheBehaviorOfAutoFixtureAutomockingWithMoq.aspx http://blog.ploeh.dk/2010/11/13/RhinoMocksbasedAutomockingWithAutoFixture.aspx
With the Build method itself, there aren’t that many options, but you can do something like this: var constrainedText = fixture.Create<string>().Substring(0, 10); var mc = fixture .Build<MyClass>() .With(x => x.SomeText, constrainedText) .Create(); However, personally, I don’t see how this is any better or easier to understand that this: var mc = fixture .Build<MyClass>() .Without(x => … Read more
Register and Inject Once upon a time, there was no Inject and no Freeze; Register ruled the code. Back then, there was a Register overload defined thusly: public static void Register<T>(this IFixture fixture, T item) However, it had to share the API with this close relative: public static void Register<T>(this IFixture fixture, Func<T> creator) The … Read more
In Verify Moq by default checks reference equality for arguments so it only passes when you provide the same instances (except if you’ve overriden Equals) in your tests and in your implementation. In you case the expectedA.Value just returns the new A { P1 = 1 } created in the test which, of course, isn’t … Read more
Assuming that your [AutoMoqData] attribute looks something like this: public class AutoMoqDataAttribute : AutoDataAttribute { internal AutoMoqDataAttribute() : base(new Fixture().Customize(new AutoMoqCustomization())) { } } Then, yes, those two tests are equivalent. Both [Fact] and [Theory] attributes are defined by xUnit.net. The [Fact] attribute is used by the xUnit.net test runner to identify a ‘normal’ unit … Read more