Categorized list of AutoFixture questions on Stack Overflow

The complete list can be found here.

AutoFixture.Auto[Moq/RhinoMocks/FakeItEasy/NSubstitute]

• What is AutoFixture AutoMoq?
• Differences between Moq and AutoFixture
• How to verify a method was called
• Using verify to confirm expected parameter values in Moq’s Mock class
• Creating a hybrid of a Mock and an Anonymous object using Moq and AutoFixture
• Test a class that takes a Factory
• Repetitive code in Unit Tests
• Integration Test an application using Castle Windsor
• AutoFixture as an Auto-mocking Container vs Auto-mocking differences
• Create an instance of a type that contains properties with an interface type
• How to return results from injected services in an instantiated object
• Mocked methods returning a Frozen instance
• Proper use of AutoFixture AutoMoq
• AutoData Theories with AutoFixture using manual fakes
• How to express a Unit Test declaratively?
• Imperative to Declarative Unit Test
• Auto-mocking using FakeItEasy
• Auto-mocking the SUT

AutoFixture.Idioms

• When I pass input to the parameter x of a method, supplying the other parameters anonymously, the result is ..
• Simplifing Unit Testing DDD Value objects Equality
• Verify invalid constructor parameters

AutoFixture.Xunit

• Integration Test an application using Castle Windsor
• AutoFixture with ‘weak’ types
• Proxies in data integration tests
• AutoFixture with derived types
• Mocked methods returning a Frozen instance
• Proper use of AutoFixture AutoMoq
• How to express a Unit Test declaratively
• Imperative to Declarative Unit Test
• Auto-mocking using FakeItEasy
• What are the principles behind AutoFixture’s declarative way of setting up a fixture?
• PropertyDataAttribute and heterogeneous parameters

Customizations

• How to create a list of types with predefined values
• How to set a private setter of an Automatic Property by calling a method
• Generate anonymous number for string property
• Execute a delegate at object creation time
• How to limit the length of generated strings
• Integration Test an application using Castle Windsor
• Selecting the greediest constructor by default
• How to call a base method for all instances of classes that inherit from it
• Creating ASP.NET MVC Controller instances without setting property values
• How to generate objects when there are multiple paths to a child entity
• AutoFixture with ‘weak’ types
• Proxies in data integration tests
• Supplying values for inherited properties
• Mocked methods returning a Frozen instance
• Creating ASP.NET MVC Controller instances
• Using Customize with seeded property
• PropertyTypeOmitter (System.Runtime.Serialization.ExtensionDataObject example)
• Customizing constructor parameter values
• Ignore virtual properties
• Creating an ISpecimenBuilder for a type
• Imperative to Declarative Unit Test

Freeze, Inject

• How to verify a method was called
• How to Freeze a Null Reference
• AutoFixture with ‘weak’ types
• AutoFixture with derived types
• Auto-mocking using FakeItEasy
• Supply a known value for one constructor parameter

Likeness, Likeness as Resemblance

• Compare only matching properties
• Likeness applied to sequences
• Custom Assertion
• Using verify to confirm expected parameter values in Moq’s Mock class
• Likeness applied to sequences
• How to use ‘EqualsWhen’

Refactoring

• Minimizing the Arrange phase
• Repetitive code in Unit Tests
• Imperative to Declarative Unit Test

The GitHub way of blog discussion and commenting

Using the underlying power of GitHub, blog authors often take a step further and roll their own discussion and commeting systems.

The best examples are:

• Add a comment by sending a pull request by Mark Seemann
• Add a comment through the GitHub API by Ivan Zuzak
• Add a comment as a GitHub issue by Zach Holman

With the evolution of blog-aware static site generators, like Jekyll, GitHub is becoming a central part for hosting both blog content and comments.

Hackers, Developers, Programmers

The definitions about Hackers, Developers, and Programmers, that I like best are:

“Hackers are generally loners who don’t care if others can figure out their code (at least while they are in the mode or role of hacking). Thus, they build their own little world in it that fits themselves nicely so that they can hack fast, but the rest of the world be damned.” — c2.com/wiki

“On the ‘programmer’ vs. ‘developer’ debate: ‘Programmer’ focuses on the ‘craft’. ‘Developer’ focuses on the business. Both are valuable.” — @ploeh on twitter

I am a programmer — You?

xUnit.net Attributes Execution Order

The test below uses the xUnit.net framework and executes twice, since it is decorated with two data sources. The first data source is the built-in [InlineData] and the second data source is the custom [StringData].

[Theory]
[InlineData("foo", "bar")]
[StringData]
[Intercept]
public void Test(string a, string b)
{
}

xUnit.net invokes in exact order:

Initialization

1. [InlineData] consturctor
2. [StringData] consturctor
3. [InlineData] IEnumerable<object[]> GetData(MethodInfo, Type[])
4. [StringData] IEnumerable<object[]> GetData(MethodInfo, Type[])

1st Run

1. [Intercept] consturctor
2. [Intercept] void Before(MethodInfo)
3. [Theory] supplying values for a and b taken from either [InlineData] or [StringData]
4. [Intercept] void After(MethodInfo)

2nd Run

1. [Intercept] consturctor
2. [Intercept] void Before(MethodInfo)
3. [Theory] supplying values for a and b taken from either [InlineData] or [StringData]
4. [Intercept] void After(MethodInfo)

Remarks

[Intercept] is defined as:

internal class InterceptAttribute : BeforeAfterTestAttribute
{
    public override void Before(MethodInfo methodUnderTest)
    {
    }

    public override void After(MethodInfo methodUnderTest)
    {
    }
}

It allows code to be run before and after each test is run.

[StringData] is defined as:

internal class StringDataAttribute : DataAttribute
{
    public override IEnumerable<object[]> GetData(
        MethodInfo methodUnderTest,
        Type[] parameterTypes)
    {
        yield return new object[] { "cow", "zoo" };
    }
}

XCOPY deployment for Code Contracts

If you don’t wish to install Code Contracts through the Windows Installer:

• Go to \Program Files (x86)\MSBuild\4.0\Microsoft.Common.Targets\ImportAfter folder.
• Create a new file with name CodeContractsAfter.targets and paste the following XML:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <CodeContractsInstallDir Condition="'$(CodeContractsInstallDir)'==''">CONTRACTS_PATH</CodeContractsInstallDir>
  </PropertyGroup>
  <Import Condition="'$(CodeContractsImported)' != 'true' AND '$(DontImportCodeContracts)' != 'true'" 
          Project="$(CodeContractsInstallDir)MsBuild\v4.0\Microsoft.CodeContracts.targets" />
</Project>

• Extract the contents from the Code Contracts Windows Installer using the lessmsi tool.
• Locate the Contracts folder in the extracted contents.
• Replace the CONTRACTS_PATH in CodeContractsAfter.targets with the actual Contracts folder location.

Legacy Code Risk

Taking the risk to adjust the architecture of a legacy system and extend it in a nice and clean way.

Creating a context:

• Complex domain (e.g. life insurance)
• Many technologies are used, tightly coupled (e.g. Redis, db40, iBATIS, Quartz, Sparks, etc).
• The model has been designed around the Active Record (anti)pattern.
• In a few places there are also DAOs and/or Repositories.
• The Service Locator (anti)pattern has been applied everywhere.
• Almost everywhere, the SRP has been violated.
• Communication with any external Web Service is not guarded with a Circuit Breaker.
• And yes.. there are no tests..

(All the above yield sad customers, bugs, and slow performance.)

Against messy, tightly coupled, legacy code.

• Strive toward real SOLID principles
• Instead of doing Test-After Development Sins write test code trying to drive the SUT API and safely refactoring afterwards. The non-relevant Test Fixture setup is automated with AutoFixture decleratively with the xUnit.net extension.
• Instead of using the Service Locator use Dependency Injection patterns, such is Constructor Injection.
• Instead of using Active Record, Repositories and DAOs consider using Queries and Commands (as described in the first half of this post). This might result in more classes but each class is going to have one responsibility instead of two or more.

Why it is a risk?

The above require a few changes in the system architecture (e.g. in order to be possible to not use Service Locators, in order to be possible to use Services to query from the database instead of the Active Record way, etc.).

While the required changes are going to (initially) slow down the development process at the end the overall development is going to be faster.

Would you take the risk?

« previous entries