question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Creating a fake with provided constructor arguments ordering should not matter

See original GitHub issue

Here an idea:

When I create a fake it allows me to specify constructor arguments. My opinion is that when there are no constructor arguments of the same type the order of the constructor arguments should not matter in the provided object array. Here the repro:

public class OtherInfrastructureStuff
{
    private readonly JustAnotherTool tool;

    private readonly JsonTextWriter textwriter;

    public OtherInfrastructureStuff(JustAnotherTool tool, JsonTextWriter textwriter)
    {
        this.tool = tool;
        this.textwriter = textwriter;
    }
 }

This works:

[TestFixture]
public class SomeInfrastructureTest
{
    private OtherInfrastructureStuff other;

    private SomeInfrastructureStuff testee;

    [SetUp]
    public void SetUp()
    {
        this.other =
           A.Fake<OtherInfrastructureStuff>(
               options =>
               options.WithArgumentsForConstructor(
                   new object[] { A.Fake<JustAnotherTool>(), new JsonTextWriter(new StringWriter(new StringBuilder())) }));

        this.testee = new SomeInfrastructureStuff(this.other);
    }
 }

as soon as I swap out the parameters the setup fails:

[TestFixture]
public class SomeInfrastructureTest
{
    private OtherInfrastructureStuff other;

    private SomeInfrastructureStuff testee;

    [SetUp]
    public void SetUp()
    {
        this.other =
           A.Fake<OtherInfrastructureStuff>(
               options =>
               options.WithArgumentsForConstructor(
                   new object[] { new JsonTextWriter(new StringWriter(new StringBuilder())),  A.Fake<JustAnotherTool>() }));

        this.testee = new SomeInfrastructureStuff(this.other);
    }
 }

I see that you cannot provide this in case the constructor looks in example like this:

public class OtherInfrastructureStuff
{
    private readonly JustAnotherTool tool;

    private readonly JustAnotherTool anotherTool;

    public OtherInfrastructureStuff(JustAnotherTool tool, JustAnotherTool anotherTool)
    {
        this.tool = tool;
        this.anotherTool= anotherTool;
    }
 }

But with multiple different parameters the order should not matter. Thoughts?

Daniel

Issue Analytics

  • State:closed
  • Created 10 years ago
  • Comments:6 (6 by maintainers)

github_iconTop GitHub Comments

1reaction
adamralphcommented, May 23, 2013

Interesting. What about when the constructor is declared in terms of interfaces? E.g.

public Foo(IBar bar, IInheritsFromIBar baz)
A.Fake<Foo>(o => o.
    WithArgumentsForConstructor(new object[] { new Bar(), new InheritsFromBar());

I wonder how it easy it would be to come up with a good enough type resolution algorithm.

0reactions
adamralphcommented, Feb 6, 2016

@danielmarbach thanks for raising this. Given lack of enthusiasm to have this in the core package we decided to close this.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Confusion regarding order of the parameter in constructor ...
I see that the method is being called with unexpected behavior. setHeight() actually performs as expected but it is not implemented as you'd ......
Read more >
Class Constructor that Takes Two Arguments of the Same ...
My real concern is my title - the "final" class takes two parameters of the same interface type, but they MUST be in...
Read more >
Tutorial - Mocking
There are three different mocking annotations we can use when declaring mock fields and parameters: @Mocked , which will mock all methods and...
Read more >
Creating Mock Classes
The constructors of the base mock ( MockFoo ) cannot have arguments passed by non-const reference, which happens to be banned by the...
Read more >
Interaction Based Testing
If a mock object is only used for stubbing, it's common to declare interactions at mock creation time or in a setup: block....
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found