1

Closed

Support theory data in class fixtures

description

The DataAttribute can only apply to methods. IClassFixture requires TFixture implement new(). I'd like to be able to supply fixture data in the form of constructor arguments for test case class per fixture in the same manner as theories.
Closed Mar 22 at 10:40 PM by BradWilson
After discussion, we have decided not to do this.

comments

bartelink wrote Jul 25, 2013 at 12:23 AM

Any examples of how you might leverage this? (There's an upvote in it for ya :P)

BradWilson wrote Aug 18, 2013 at 5:12 PM

+1, would like to see the intended usage, because it's not clear to me from the paragraph above.

jbogard wrote Sep 26, 2013 at 12:13 PM

Something along the lines like:
public class Account_ForApprovalTests {
    Account _account;

    [CtorTheory]
    public AccountApprovalTests(IMediator mediator) {
        _account = new Account();
        mediator.Send(new ApproveAccountMessage{ Account = account });
    }

    [Fact]
    public void Should_mark_account_as_approved() {
        _account.Status.ShouldEqual(Status.Approved);
    }

    [Fact]
    public void Should_mark_approval_date_as_today() {
        _account.DateApproved.ShouldEqual(DateTime.Today);
    }
    // more asserts below
}
I basically have 2 styles of tests - test-class-per-class, and test-class-per-fixture.

In test-class-per-fixture, my structure (from NUnit) was:

Fixture Setup
  • Arrange
  • Act
Test 1
  • Assert
Test 2
  • Assert
It's the BDD-style context-specification format. Arrange/Act in the fixture setup, assert in each of the tests.

IUseFixture is essentially setter injection, except that I still can't influence creation - xUnit just does Activator.CreateInstance.

Ideally, I could have my behavioral-style tests match more closely to regular code - constructor takes arguments, does initial work, and each test method merely makes assertions on the result. With each test method I can then get assertions on each aspect of behavior of the SUT.

BradWilson wrote Oct 27, 2013 at 12:12 AM

I'll admit I'm confused.

v2 has IClassFixture<T> (which is equivalent to v1's IUseFixture<T>) which would allow you to do this without having control over creating the object. If you want to control the creating of an object from your constructor, of what particular value is IUseFixture<T>? Why not just create the object yourself?