Testing with immutable structs

Question

We use a lot of immutable structs in our code. We want Pex to test classes that consume immutable structs. But Pex has difficulty with this. Here's an example:

public struct UserInfo
{

public UserInfo(string name, int id)

: this()

{

this.Name = name;
this.Id = id;

}

public string Name { get; private set; }
public int Id { get; private set; }

}

And the consumer that we want to test with Pex:

public class Consumer
{

public Consumer(UserInfo info)
{

...

}

}

Pex can't test consumer. It spits out a commented-out unit test:

        [Test]

        [Ignore("the body of the test was commented out as it might not be compilable")]

        [PexGeneratedBy(typeof(Consumer))]

        [PexNotCompilable]

        public void Constructor01()

        {

            /* 

            Consumer consumer;

            UserInfo userInformation = default(UserInfo);

            // cannot set UserInfo.<Name>k__BackingField: field is not visible

            userInformation.Name = "";

            consumer =

              this.Constructor(s0, userInformation);

            // validation of result values is supported for primitive types only

            */

        }

I don't care that Pex can't figure out the constructor logic. Just spit out a default UserInfo and move along. Why doesn't this work?

Or better yet, have Pex figure out that it can use the constructor.

This is a major blocker for us, as we use a lot of these immutable structs everywhere.

---

Tech, life, family, faith: http://judahgabriel.blogspot.com

Answer 1

This is a limitation of the current Explorable implementation (i.e. structs not supported). The only workaround for now is to write the code so that it takes name and id, then construct the struct inside the test.

---

Jonathan de Halleux

Answer 2

Hmm. Shoot. I'm afraid that work-around is quite painful for us -- we have hundreds of such classes that would need to be modified.

I guess we will have to revert to plain old unit testing for those cases.

I hope you guys address that in the near future.

---

Tech, life, family, faith: http://judahgabriel.blogspot.com

Answer 3

Actually there's another solution, the Creatable. This is another way to create object and value types that assumes that you can set entirely the state of instance without control flow. Take a look at

http://research.microsoft.com/pex/wiki/Creatables.html

---

Jonathan de Halleux

Answer 4

For example, in your case, the following annotation does the trick for the UserInfo struct:

[assembly: Microsoft.Pex.Framework.Creatable.PexCreatableByConstructorAndSetters(
    typeof(UserInfo), null, false,
    "<Name>k__BackingField", "<Id>k__BackingField")]

You can put such global settings in the Properties\PexAssemblyInfo.cs file in the test project that Pex generates once you save a test.
What is important is that you list the fields of the class in the order in which they are passed to the constructor, using the name mangling as shown above.

Admittedly, that is not a nice or maintainable annotation. I will add a work item that Pex should do an automatic analysis of the constructor code for this particular pattern, as it should be quite common.

Nikolai

Answer 5

We are tracking this issue internally.

---

Jonathan de Halleux

Answer 6

Update from the Pex team: An automatic detector for such data types has been implemented, and will be part of the next Pex release.
Then it Pex will do the right thing out of the box and no annotation will be needed.

Nikolai

Answer 7

Thanks, Jonathan and Nikolai! This was a major blocker for us. Now that it has been fixed, we will give Pex a spin again here at work.

Thanks again, great work.

---

Tech, life, family, faith: http://judahgabriel.blogspot.com