# Saturday, September 29, 2007

In Pex, we have our own version of all (and more) collection classes from the BCL. This duplication may sound stupid but there's a very good reason behind it: since Pex instruments code (i.e. rewrites IL), the BCL collections might be instrumented as well... leading to a poorer performance (instrumented code is slower for many reasons). Therefore, to avoid this situation, we ended up using our own implementation which never gets instrumented.

While using our collections, we added 2 features that we like a lot: readonly interfaces and small collections.

Readonly interfaces

Readonly interfaces are handy to 'safely' expose collections, once you start using them you get hooked:

  • ICountable<T>, a readonly enumerable with a Count.
interface ICountable<T> : IEnumerable<T>
{
    int Count {get;}
}
  • ICopyable<T>, a countable that can be copied around,
interface ICopyable<T> : ICountable<T>
{
    void CopyTo(T[] array, int index);
}
  • IIndexable<T>, a indexed collection
interface IIndexable<T> :  ICopyable<T>
{
    T this[int index] { get; }
}

We also have a couple more interfaces for dictionary style collections but you get the idea.

Small Collections

Small collections are optimized collections with 0, 1 or 2 elements. Depending on your scenario, these can improve the performance of your application while lowering the pressure on the GC (create less objects -> less stuff to garbage collect). If you create a lot of objects which each have collections, ask yourself: are you lazy allocating the collections? what should be the initial size of the collection? do you expect more than one element on average?

posted on Saturday, September 29, 2007 11:33:15 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [0]
# Sunday, September 23, 2007

xUnit, the new variation on the 'unit test framework' theme comes with support for data driven tests: 'Theories' (funny name by btw). Pex is a plugin for test frameworks, so we've added support for xUnit as well.

[PexClass] // xUnit does not have fixture attributes
public class MyTests
{
    [Theory, DataViaXXXX] // xUnit theories
    [PexTest] // let pex help you 
    public void Test(int a, ....)
    {}
}

posted on Sunday, September 23, 2007 9:26:32 AM (Pacific Daylight Time, UTC-07:00)  #    Comments [0]
# Thursday, September 13, 2007

Z3 is the high performance theorem prover that Pex uses to solve constraint systems (and find bugs). You can now play with it too! 

http://research.microsoft.com/projects/z3/

Z3 is written in C++, but it has a .Net API to make you happy.

posted on Thursday, September 13, 2007 5:01:41 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [1]
# Friday, September 07, 2007

In a previous, we were looking at partial trust the lack of support for it. In this post, I'll show the key 'fixes' that we did to make Pex 'partial trust' aware.

Simulating Partial Trust

The easiest way to run under partial trust is to run your .net application from the network. However, in the context of a test framework, this would not work since many required permissions would not be granted (reflection, i/o, etc...). So we need a new AppDomain whose security policy considers the test framework assemblies as fully trusted.

  • Get a new AppDomain:
string trust = "LocalIntranet";
AppDomain domain = AppDomain.CreateAppDomain(trust);
  • Load the named permission set
PermissionSet permission = GetNamedPermissionSet(trust);
  • Create the code group structure that associate the partial trust permission to any code
UnionCodeGroup code= new UnionCodeGroup(
    new AllMembershipCondition(),
    new PolicyStatement(permission, PolicyStatementAttribute.Nothing));
  • give full trust to each test framework assembly:
StrongName strongName = CreateStrongName(typeof(TestFixtureAttribute).Assembly);
PermissionSet fullTrust = new PermissionSet(PermissionState.Unrestricted);
UnionCodeGroup fullTrustCode = new UnionCodeGroup(
new StrongNameMembershipCondition(strongName.PublicKey, strongName.Name, strongName.Version),
new PolicyStatement(fullTrust, PolicyStatementAttribute.Nothing));
code.AddChild(fullTrustCode);
  • Assign the policy to the AppDomain
PolicyLevel policy = PolicyLevel.CreateAppDomainLevel();
policy.RootCodeGroup = code;
domain.SetAppDomainPolicy(policy);

This is basically it (the rest of the details are left as an exercise :)).

Let them call you

Make sure to add the AllowPartiallyTrustedCallers to the test framework assembly otherwize users won't be allowed to call into it...

A twist...

Pex is bit invasive when it comes to partial trust. Pex rewrites the IL at runtime and turns all method bodies into... unsafe code (that is unverifiable). At this point, any will not run because of the SkipVerification permission.

No problemo, just add it to the permissionset:

permission.AddPermission(
    new SecurityPermission(SecurityPermissionFlag.SkipVerification)
    );

 

posted on Friday, September 07, 2007 11:39:22 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [0]
# Tuesday, September 04, 2007

Writing code that will run in partial trust is tricky... and writing unit tests for it turns out to be even trickier. Does your favorite unit test framework support partial trust?

After looking on NUnit, MbUnit or VSTT, it did not look like so (if I overlooked this feature, don't hesitate to point it out to me). No magic command line flag or custom attribute to get the work done.

Even more interesting, the test framework assemblies don't have the AllowPartiallyTrustedCallersAttribute... so you can't even use their assertion classes in partial trust as it will trigger a SecurityException... Good stuff.

posted on Tuesday, September 04, 2007 10:01:05 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [1]